linux-kernel - Re: [PATCH] x86: add PCI IDs to k8topology

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, 28 Jan 2008 20:12:46 -0800
From:	Yinghai Lu <Yinghai.Lu@....COM>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Joachim Deguara <joachim.deguara@....com>, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	Dean Roe <roe@...y.com>
Subject: Re: [PATCH] x86: add PCI IDs to k8topology_64.c

On Monday 28 January 2008 07:48:06 pm Andi Kleen wrote:
> "Joachim Deguara" <joachim.deguara@....com> writes:
> 
> > Quick history, this is a harmless patch that got dropped by Andi as a mixup to 
> 
> It's not harmless.
> 
> > dropping another patch of mine that was made obsolete by Yinghai.
> > http://thread.gmane.org/gmane.linux.kernel/559581
> 
> No that's not the correct history. The correct history is that 
> I intentionally rejected this patch because the old k8topology
> hack should really not be used anymore on modern machines (especially
> not on Quad Cores). SRAT is the far better way to handle this problem
> because it has a proper abstraction.
> 
> The problem with k8topology.c is that it needs to know very low level
> information (like HT node numbers etc.) the kernel should not really
> need to know and which are difficult to handle generally without
> motherboard specific knowledge. 
> 
> k8topology.c mostly guesses, which was never a good way to handle this. 
> Also in in the various "node has no memory" cases it needs quite
> hackish fallback heuristics which will be always fragile. Then there
> are some ugly interactions with quad cores. And some other issues
> 
> I still think the patch a bad idea because adapting this file all
> the time is a long term maintenance issue. I can say that as 
> the original author :-) It was just a quick hack long ago
> to get NUMA going early. But now it far outlived its usefulness
> and adapting it to modern machines is the wrong direction. 
> 
> Best is to phase k8topology out.

then with acpi=off, we can not use numa any more.

also there are some users are using LinuxBIOS or other firmware that doesn't have  or like ACPI support. but they still need numa.
for them ACPI doesn't help.

YH

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