Re: [PATCH] x86: add /proc/cpuinfo/physical id quirks

[Alex Chiang <achiang@hp.com>]

* H. Peter Anvin <hpa@zytor.com>:
> On 08/20/2009 02:26 PM, Suresh Siddha wrote:
> > On Thu, 2009-08-20 at 14:20 -0700, Alex Chiang wrote:
> >> It turns out I need to rework my patch anyway because I need
> >> to think about the case where a user disables some cores in
> >> the BIOS, in which case my (fragile) table selection scheme
> >> falls apart.
> > 
> > These are the sort of reasons why we want topology detection
> > to be completely based on what cpuid instruction says and
> > nothing else.
> 
> I agree... if this ID is used for topology detection, we
> shouldn't replace it arbitrarily with information from BIOS
> just to hope that it matches the motherboard stencil.

Well, to be fair, in my patch, the phys_proc_ids remained
consistent for a given physical processor package.

That is, if all the cores in a socket initially started with
phys_proc_id X, they all ended up with phys_proc_id Y.
Additionally, no other cores in other sockets ended up with Y.
So in that sense, there was no real change in how we detected CPU
topology. All the core/thread/sibling ids remained correct and
unchanged.

Second, my patch wasn't sticking arbitrary information in from
BIOS; it was merely rearranging the existing phys_proc_ids.

> *Furthermore*, there is no reason why motherboard stencilAs are
> purely numeric... consider the rather obvious case of two rows
> of four CPUs; they may have CPU slots labelled A1, A2, A3, A4,
> B1, B2, B3, B4.  It might very well be the right thing to
> support arbitrary strings for platforms we recognize.

But yes, I do agree that this is a good point, and even here at
HP, we have other platforms with complex physical topologies.

Once you go down this path of thinking though, ACPI starts
looming, and that has other issues associated with it (in my
mind, mostly around the cleanliness of implementation as ACPI
starts poking its fingers everywhere).

> As such I think we should have a socket name field in both
> /proc/cpuinfo and sysfs.

Well, now we have 2 yeas (hpa and Suresh), 1 nay (Andi), and 1
"tell me what you'd like" (me ;)

/ac