Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex

[Linus Torvalds <torvalds@linux-foundation.org>]

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 crazy
behavior just makes me convinced that there is no way in hell I should
*ever* take your sysconfig patch, since all your analysis for it is
totally worthless?

JUST LOOK AT THE NUMBERS, for chrissake!

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

     6.40%        exim  [kernel.kallsyms]           [k] format_decode
     5.26%        exim  [kernel.kallsyms]           [k] page_fault
     5.05%        exim  [kernel.kallsyms]           [k] vsnprintf
     3.55%        exim  [kernel.kallsyms]           [k] number
     3.00%        exim  [kernel.kallsyms]           [k] copy_page_c
     2.88%        exim  [kernel.kallsyms]           [k] read_hpet
     2.38%        exim  libc-2.13.90.so             [.] __GI_vfprintf
     1.92%        exim  [kernel.kallsyms]           [k] kstat_irqs
     1.53%        exim  [kernel.kallsyms]           [k] find_vma
     1.47%        exim  [kernel.kallsyms]           [k] _raw_spin_lock
     1.40%        exim  [kernel.kallsyms]           [k] seq_printf
     1.34%        exim  [kernel.kallsyms]           [k] radix_tree_lookup
     1.21%        exim  [kernel.kallsyms]           [k]
page_cache_get_speculative
     1.20%        exim  [kernel.kallsyms]           [k] clear_page_c
     1.05%        exim  [kernel.kallsyms]           [k] do_page_fault

I can pretty much guarantee that it doesn't do just one /proc/stat
read 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 you
had, you would ALSO have seen that you are totally full of sh*t. Glibc
at no point caches anything.

So repeat after me: stop making excuses and lying about glibc. It's
crap. 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 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.

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

                           Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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@kvack.org"> email@kvack.org </a>