Giuseppe Scrivano wrote:
> Subject: [PATCH] nproc: A new program to count the number of processors
s/number of/available/
>
> * AUTHORS: Add my name.
> * NEWS: Mention it.
> * README: Likewise.
> * bootstrap.conf (gnulib_modules): Add nproc.
> * doc/coreutils.texi (nproc invocation): Add nproc i
I have updated the new nproc program to use this change in gnulib.
Thanks to Bruno, now nproc has not any logic inside but it is a mere
wrapper around the gnulib module.
I used as arguments to the new program the same names used by the
`nproc_query' enum, except using --overridable instead of
Bruno Haible writes:
> There were no further comments except Pádraig's one, so I committed the
> change:
>
> 2009-11-04 Bruno Haible
>
> Make num_processors more flexible and consistent.
> * lib/nproc.h (enum nproc_query): New type.
> (num_processors): Add a 'query' argument.
Paolo Bonzini wrote:
> On 11/04/2009 01:24 AM, Pádraig Brady wrote:
>> BTW, it wouldn't be ambiguous to the program, nor would it
>> be different than the existing meaning, but as you say,
>> users could mistakenly do -P0 when they meant -0P.
>> So I'll make the arg mandatory, but what to choose?
>
Kamil Dudka wrote:
...
>> I saw similar numbers when timing rm -rf and chmod -R.
>> Thus, I'm reluctant to impose such a penalty without
>> first exhausting all other possibilities.
>
> Yes, it makes sense. However what other possibilities do we have actually?
Change the kernel, or find a way to m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 10/30/2009 6:53 AM:
>> I can't reproduce on current debian testing, so it is likely an old bug.
>
> The Linux man pages are explicit that older kernels had a bug where
> UTIME_OMIT with a non-zero seconds field failed with E
Hi Jim,
On Wed November 4 2009 13:02:33 Jim Meyering wrote:
> I've built with it and compared before/after performance
> using an all-directories hierarchy on a tmpfs file system.
>
> The result is a >10% performance decrease in this contrived worst case:
thanks for stating the upper boundary es
Kamil Dudka wrote:
> On Sat October 31 2009 12:22:01 Jim Meyering wrote:
>> I'm trying to reconcile this file system's behavior with
>> fundamental assumptions about unchanging device/inode,
>> and as a result am having second thoughts.
>>
>> What event causes the directory's stat.st_dev to change?
There were no further comments except Pádraig's one, so I committed the
change:
2009-11-04 Bruno Haible
Make num_processors more flexible and consistent.
* lib/nproc.h (enum nproc_query): New type.
(num_processors): Add a 'query' argument.
* lib/nproc.c: Include