On Wed, Jun 15, 2011 at 3:19 PM, Andi Kleen <ak@linux.intel.com> wrote:>> Caching doesn't help because the library gets reinitialized in every child> (it may already do caching, not fully sure for this; it does it for other> sysconfs at least)

Why the hell do you continue to make excuses for glibc that are*clearly*not*true*?

Stop this insanity, Andi. Do you realize that this kind of crazybehavior just makes me convinced that there is no way in hell I should*ever* take your sysconfig patch, since all your analysis for it istotally worthless?

JUST LOOK AT THE NUMBERS, for chrissake!

When format_decode is 7% of the whole workload, and the top 15functions of the profile look like this:

I can pretty much guarantee that it doesn't do just one /proc/statread per fork() just to get the number of CPU's.

/proc/stat may be slow, but it's not slower than doing real work -unless you call it millions of times.

And you didn't actually look at glibc sources, did you? Because if youhad, you would ALSO have seen that you are totally full of sh*t. Glibcat no point caches anything.

So repeat after me: stop making excuses and lying about glibc. It'scrap. End of story.

> I don't think glibc is crazy in this. It has no other choice.

Stop this insanity, Andi. Why do you lie or just make up arguments? WHY?

There is very clearly no caching going on. And since exim doesn't evenexecve, it just forks, it's very clear that it could cache things justONCE, so your argument that caching wouldn't be possible at that levelis also bogus.

I can certainly agree that /proc/stat isn't wonderful (it used to bebetter), but that's no excuse for just totally making up excuses forjust plain bad *stupid* behavior in user space. And it certainlydoesn't excuse just making shit up!