[glibc] Fix Linux sysconf(_SC_NPROCESSORS_[CONF|ONLN]) performance problem

[Linus Torvalds]

It turns out that apparently libdb (and possibly others) call
sysconf(_SC_NPROCESSORS_ONLN) (aka get_nprocs()) a *lot*.

The claimed reason is that it wants to "optimize" its locking behavior
wrt the number of CPU's in the system, but it's pretty clear that
libdb was assuming that the sysconf() would just return a constant
value or just otherwise be very low-overhead, because what actually
happens on Linux is not an optimization, but instead glibc spending
endless amounts of time in the kernel just generating /proc files
because it tries to parse /proc/stat.

So people who actually know about this just use a LD_PRELOAD thing to
override the slow glibc implementation, while normal people just get
bad performance because they never realize that the system is spending
a quarter of the CPU cycles just generating and parsing /proc/stat
files (that "quarter of the CPU cycles" is a rough estimate from a
real profile of an exim benchmark).

Rather than forcing people to use LD_PRELOAD and take over sysconf(),
or letting normal people down, shouldn't we just make the glibc
implementation better instead?

This patch does that in two different ways:

 - cache the value in a static variable, so that if/when there are
multiple calls, we don't spend time recalculating the number of CPU's
in the system unnecessarily.

 - while the /proc/stat parsing approach remains as a fallback, use
sched_getaffinity() to much more quickly and simply get the number of
processors that this process is allowed to use. That is not only much
simpler, but is actually also potentially more accurate wrt the number
of processors actually available to the process.

I'd argue that the /proc/stat parsing might as well be deleted
entirely, but in trying to keep the patch minimal I kept it as a
fallback.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---

This goes out to a random selection of top committers for the last six
months according to the glibc git tree and to libc-alpha. If there are
better people/lists out there, let me know.

Comments? The caching might be considered technically "wrong", but the
value it caches is badly defined anyway, and the current glibc code
will not even necessarily return consistent values for
_SC_NPROCESSORS_CONF vs _SC_NPROCESSORS_ONLN, so whatever.

If you just want the sched_getaffinity() approach, I can send a
castrated patch instead.

                Linus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-patch
Size: 2005 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20110616/2821323f/attachment.bin>