Re: [PATCH] core-count: A new program to count the number of cpu cores

2009-11-04 Thread Pádraig Brady
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

Re: [PATCH] core-count: A new program to count the number of cpu cores

2009-11-04 Thread Paolo Bonzini
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

Re: [PATCH] core-count: A new program to count the number of cpu cores

2009-11-04 Thread Giuseppe Scrivano
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.

Re: [PATCH] core-count: A new program to count the number of cpu cores

2009-11-04 Thread Pádraig Brady
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? >

Re: FTS not ready for a remount during traversal

2009-11-04 Thread Jim Meyering
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

Re: test-utimens.h:105: assertion failed

2009-11-04 Thread Eric Blake
-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

Re: FTS not ready for a remount during traversal

2009-11-04 Thread Kamil Dudka
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

Re: FTS not ready for a remount during traversal

2009-11-04 Thread Jim Meyering
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?

Re: [PATCH] core-count: A new program to count the number of cpu cores

2009-11-04 Thread Bruno Haible
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