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, 5 May 2009 11:35:20 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Andreas Herrmann <andreas.herrmann3@....com>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] x86: adapt CPU topology detection for AMD Magny-Cours

> Best example is node interleaving. Usually you won't get a SRAT table
> on such a system.

That sounds like a BIOS bug. It should supply a suitable SLIT/SRAT
even for this case. Or perhaps if the BIOS are really that broken
add a suitable quirk that provides distances, but better fix the BIOSes.

 Thus you see just one NUMA node in
> /sys/devices/system/node.  But on such a configuration you still see
> (and you want to see) the correct CPU topology information in
> /sys/devices/system/cpu/cpuX/topology. Based on that you always can
> figure out which cores are on the same physical package independent of
> availability and contents of SRAT and even with kernels that are
> compiled w/o NUMA support.

So you're adding a x86 specific mini NUMA for kernels without NUMA
(which btw becomes more and more an exotic case -- modern distros
are normally unconditionally NUMA) Doesn't seem very useful.

My problem with that is that imho the x86 topology information is already
too complicated -- i suspect very few people can make sense of it --
and you're making it even worse, adding another strange special case.

On the other hand NUMA topology is comparatively straight forward and well 
understood and it's flexible enough to express your case too.

>    physical package == two northbridges (two nodes)
> 
> and this needs to be represented somehow in the kernel.

It's just two nodes with a very fast interconnect.

> 
> > Who needs this additional information?
> 
> The kernel needs to know this when accessing processor configuration
> space, when accessing shared MSRs or for counting northbridge specific
> events.

You're saying there are MSRs shared between the two in package nodes?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ