linux-kernel - Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets

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]

Date:	Mon, 24 Sep 2012 09:30:05 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Mel Gorman <mgorman@...e.de>, Borislav Petkov <bp@...en8.de>,
	Nikolay Ulyanitsky <lystor@...il.com>,
	Mike Galbraith <efault@....de>, linux-kernel@...r.kernel.org,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to
 3.6-rc5 on AMD chipsets - bisected

On Mon, Sep 24, 2012 at 9:12 AM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>
> So we're looking for an idle cpu around @target. We prefer a cpu of an
> idle core, since SMT-siblings share L[12] cache. The way we do this is
> by iterating the topology tree downwards starting at the LLC (L3) cache
> level. Its groups are either the SMT-siblings or singleton groups.

So if it'sally guaranteed to be SMT-siblings or singleton groups, then
the whole "for_each_cpu()" is a total disaster. That's a truly
expensive way to look up adjacent CPU's. Is there no saner way to look
up that thing? Like a simple circular list of SMT siblings (I realize
that on x86 that list is either one or two, but other SMT
implementations are groups of four or more).

So I suspect your patch largely makes things faster (avoid those
insane cpumask operations), but the for_each_cpu() one is still an
absolutely horrible way to find a couple of basically statically known
(modulo hotplug, which is disabled here anyway) CPU's. So even if the
algorithm makes sense at some higher level, it doesn't really seem to
make sense from an implementation standpoint.

Also, do we really want to spread things out that aggressively?
How/why do we know that we don't want to share L2 caches, for example?
It sounds like a bad idea from a power standpoint, and possibly
performance too.

                    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/