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

[Suresh Siddha]

On Fri, 2009-08-14 at 12:27 -0700, Alex Chiang wrote:
> Hm, I'm not entirely sure about that, for two reasons.
> 
> First (and this is the weaker reason), I'd prefer not to keep
> adding new fields to /proc/cpuinfo if we can help it, as it just
> makes for a continually more complicated ABI/API for userspace.

Overriding same field with different values based on the system will be
confusing. On some systems it will be derived from cpuid, some will be
based on physical slots. This is too confusing.

> Second, I guess I'm not sure what else 'physical id' /should/
> represent. I'm willing to be corrected on this point, so if I'm
> wrong, just call it simple ignorance. :)

As far as possible we kept these fields closer to what the cpuid
instruction says, so that firmware won't mess up the topology detection
etc by having wrong values in the bios tables.

> My quick grep earlier led me to believe that as long as the
> phys_proc_ids were /consistent/ then it didn't seem to matter
> what their /values/ were.

This is correct. But there are several assumptions in the patch that
might break in the future and where ever possible we simply don't want
to depend on what bios says and rather depend on what the cpu/hardware
says.

For example, we shouldn't assume that original phys proc id's calculated
from cpuid etc need not be contiguous and start from 0 etc. This is
platform dependent and may vary from one version to another version of
processor etc.

Also, you are selecting the fixup table based on number of present cpu
etc. I am just nervous that how this all workout across cpu generations
having different cores, sparsely populated sockets in the platform etc.
We just can't afford to go and fix all the old kernels if we have any
problem in the future config setups.

Easiest route will be to add a new entry in /proc/cpuinfo

thanks,
suresh


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/