linux-kernel - Re: [rfc 08/45] cpu alloc: x86 support

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:	Tue, 20 Nov 2007 13:05:24 +0100
From:	Andi Kleen <ak@...e.de>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Christoph Lameter <clameter@....com>,
	"H. Peter Anvin" <hpa@...or.com>, akpm@...ux-foundation.org,
	travis@....com, Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org
Subject: Re: [rfc 08/45] cpu alloc: x86 support

> > Yeah yea but the latencies are minimal making the NUMA logic too
> > expensive for most loads ... If you put a NUMA kernel onto those then
> > performance drops (I think someone measures 15-30%?)
>
> Small socket count systems are going to increasingly be NUMA in future.
> If CONFIG_NUMA hurts performance by that much on those systems, then the
> kernel is broken IMO.

Not sure where that number came from.

In my tests some time ago NUMA overhead on SMP was minimal.

This was admittedly with old 2.4 kernels. There have been some doubts about
some of the newer NUMA features added; in particular about NUMA slab;
don't think there was much trouble with anything else -- in fact the trouble
was that it apparently sometimes made moderate NUMA factor NUMA systems 
slower too. But I assume SLUB will address this anyways.

-Andi
-
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/