/proc/stat may be slow, but it's not slower than doing real work -
unless you call it millions of times.
I haven't analyzed it in detail, but I suspect it's some cache line
bounce, which
can slow things down quite a lot. Also the total number of invocations
is quite high (hundreds of messages per core * 32 cores)
Ok even with cache line bouncing it's suspicious.
And you didn't actually look at glibc sources, did you?
I did, but I gave up fully following that code path because it's so
convoluted :-/
Ok if you want I can implement caching in the LD_PRELOAD and see
if it changes things.
There is very clearly no caching going on. And since exim doesn't even
execve, it just forks, it's very clear that it could cache things just
ONCE, so your argument that caching wouldn't be possible at that level
is also bogus.
So you mean caching it at startup time? Otherwise the parent would
need to do sysconf() at least , which it doesn't do (the exim source doesn't
really know anything about libdb internals)
That would add /proc/stat overhead to every program execution. Is that
what you
are proposing?
-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>