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
It sucks when seen from a micro-bench POV, but does it really matter overall? The vast majority of software usually calls sysconf(_SC_NPROCESSORS_*) with very little frequency (mostly once at initialization time) anyway. That's what 50us / call? - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
