Pádraig Brady wrote:
Here's a proposed patch.
Looks good.
OK, I've applied it now.
Bruno
Pádraig Brady wrote:
Just to summarize what's happening here...
There are 3 CPU counts possible:
total = online = available
online corresponds to the CPUs enabled system wide,
whereas available is what's available to a particular
process which may be less due to affinity config.
On 10/01/10 10:32, Bruno Haible wrote:
Pádraig Brady wrote:
So what about a possible work around?
How about doing this in nproc(1):
if (num_processors(NPROC_ALL) == 1)
return num_processors(NPROC_CURRENT_OVERRIDABLE)
It should be NPROC_CURRENT, not NPROC_CURRENT_OVERRIDABLE, I think,
On Sun, Jan 10, 2010 at 11:32:50AM +0100, Bruno Haible wrote:
[...]
I like this workaround, but would prefer to have it in the nproc module
in gnulib. coreutils/src/nproc.c is purely the command-line program.
Here's a proposed patch.
It looks good, thank you.
--
ldv
pgpyzrOibAKXP.pgp
Hi,
The recently introduced nproc utility outputs wrong result when run in
--all mode inside a /proc-less /sys-less GNU/Linux chroot on a system
with several CPUs. In this environment, nproc --all always outputs 1
while plain nproc outputs correct number of available CPUs.
The underlying
when --all fails for any reason, I think we should try with the number
of available processing units, at least it is a more accurate value than
return 1 (and document this behaviour).
Bruno, Jim, what do you think?
Cheers,
Giuseppe
Dmitry V. Levin l...@altlinux.org writes:
Hi,
The
On 10/01/10 01:14, Giuseppe Scrivano wrote:
when --all fails for any reason, I think we should try with the number
of available processing units, at least it is a more accurate value than
return 1 (and document this behaviour).
Bruno, Jim, what do you think?
Just to summarize what's happening
