Re: getting processor numbers

[linux-os \(Dick Johnson\)]

On Tue, 3 Apr 2007, Ulrich Drepper wrote:

> More and more code depends on knowing the number of processors in the
> system to efficiently scale the code.  E.g., in OpenMP it is used by
> default to determine how many threads to create.  Creating more threads
> than there are processors/cores doesn't make sense.
>
> glibc for a long time provides functionality to retrieve the number
> through sysconf() and this is what fortunately most programs use.  The
> problem is that we are currently using /proc/cpuinfo since this is all
> there was available at that time.  Creating /proc/cpuinfo takes the
> kernel quite a long time, unfortunately (I think Jakub said it is mainly
> the interrupt information).
>
> The alternative today is to use /sys/devices/system/cpu and count the
> number of cpu* directories in it.  This is somewhat faster.  But there
> would be another possibility: simply stat /sys/devices/system/cpu and
> use st_nlink - 2.
>
> This last step unfortunately it made impossible by recent changes:
>
>  http://article.gmane.org/gmane.linux.kernel/413178
>
> I would like to propose changing that patch, move the sched_*
> pseudo-files in some other directly and permanently ban putting any new
> file into /sys/devices/system/cpu.
>
> To get some numbers, you can try
>
>  http://people.redhat.com/drepper/nproc-timing.c
>
> The numbers I see on x86-64:
>
> cpuinfo 10145810 cycles for 100 accesses
> readdir /sys 3113870 cycles for 100 accesses
> stat /sys 741070 cycles for 100 accesses
>
> Note that for the first two methods I skipped the actual parsing part.
> This means in the real solution the gap between those two and the simple
> stat() call is even bigger.
>
> -- 
> ÿÿ Ulrich Drepper ÿÿ Red Hat, Inc. ÿÿ 444 Castro St ÿÿ Mountain View, CA ÿÿ
>
>

Shouldn't it just be another system call? 223 is currently unused. You
could fill that up with __NR_nr_cpus. The value already exists in
the kernel.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.65 BogoMips).
New book: http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@xxxxxxxxxxxx - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/