linux-kernel - Re: [PATCH 3/3] x86: fix node_possible

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: <20090512154326.GJ19296@one.firstfloor.org>
Date:	Tue, 12 May 2009 17:43:26 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Jack Steiner <steiner@....com>
Cc:	David Rientjes <rientjes@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>, Yinghai Lu <yinghai@...nel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] x86: fix node_possible_map logic -v2

> We actually have configurations that match both scenarios above. The
> system is a blade-based system with 2 processor sockets per blade.
> Memory is socket attached and each socket is in a unique PXM.

Jack, I think the interesting part would be: If you assign the CPUs
to the next nearby node with memory. Do you see any unacceptable performance
problems from that?

I'm sure the problem could be solved, but it would be quite some work,
and that would be only worth spending if it's actually a significant
benefit.

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/