Re: [PATCH 0/3] x86: adapt CPU topology detection for AMD Magny-Cours

[Andi Kleen <andi@firstfloor.org>]

> 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@linux.intel.com -- Speaking for myself only.