linux-kernel - Re: REGRESSION: Performance regressions from switching anon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTi=Tw6je7zpi4L=pE0JJpZfeEC9Jsg@mail.gmail.com>
Date:	Wed, 15 Jun 2011 17:16:57 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Shaohua Li <shaohua.li@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Hugh Dickins <hughd@...gle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	David Miller <davem@...emloft.net>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Russell King <rmk@....linux.org.uk>,
	Paul Mundt <lethal@...ux-sh.org>,
	Jeff Dike <jdike@...toit.com>,
	Richard Weinberger <richard@....at>,
	"Luck, Tony" <tony.luck@...el.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Mel Gorman <mel@....ul.ie>, Nick Piggin <npiggin@...nel.dk>,
	Namhyung Kim <namhyung@...il.com>,
	"Shi, Alex" <alex.shi@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock
 to mutex

On Wed, Jun 15, 2011 at 3:19 PM, Andi Kleen <ak@...ux.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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/