This is the mail archive of the
mailing list for the glibc project.
Re: [glibc] Fix Linux sysconf(_SC_NPROCESSORS_[CONF|ONLN])performance problem
On Thu, Jun 16, 2011 at 14:41, Linus Torvalds
> You can argue about "you shouldn't cache" all you want, but you can't
> actually point to anything that cares, can you? In contrast, I can
> point to real programs that really care about the performance issue.
There aren't interfaces I invented. They existed before elsewhere and
the semantics is like it is implemented. We can easily resolve this
by caching if we can find out whether something changed. Having an
interface to have a one-shot query and then cache the result would
require that a different _SC_*. There are programs out there which
use these interfaces (aside from db, apparently) which try at any time
to adjust itself to the system. There have been bug reports etc in
the past because things didn't work as expected.
> You can't have it both ways, guys. Why do you care about some
> imaginary cycles in memcpy (when I can point to actual user programs
> that BREAK due to glibc changes), but then when I point to actual real
> performance data, you don't care at all and talk about some breakage
> with nothing to actually back that up.
I'm terribly sorry that I don't know all the programs which use glibc.
Fortunately I don't hear about any of them until something breaks.
> Performance is a real issue, and has real semantics too. NOBODY cares
> about some theoretical CPU hotplug event.
Unfortunately it is not theoretical anymore today, especially with
virtualization. And the semantics hasn't changed, the interface was
always as slow as it is now. People who use the interface could have
determined these interfaces as a problem forever.
I'm not opposed to any improvements. Do you think I like this
implementation while every other OS which has these interfaces
implement sysconf() using a simple syscall? What do I tell people who
rely on the documented semantic that always the correct up-to-date
value is returned when I introduce caching? "Linus said some program
he uses doesn't care about updates" is not good enough.
I really don't want to appear as refusing any change. But just
application out there depending on the current semantics is enough
reason to not cache the results. If you want to take on the
responsibility for the semantic of these functions there are easy ways
to do this. You can add functions in the vDSO at which point you can
decide upon caching, similar to the way gettimeofday etc are
optimized. If you really think it's useful to add support for
additional _SC_* values to use cached values we can talk about this.