Re: [patch 01/29] x86/cpu: Encapsulate topology information in cpuinfo_x86

[Thomas Gleixner <tglx@linutronix.de>]

On Mon, Jul 24 2023 at 19:43, Thomas Gleixner wrote:
> +struct cpuinfo_topology {
> +	u16			apicid;
> +	u16			initial_apicid;

There was an offlist question whether these should be u32 because with
X2APIC the APIC ID is 32bit wide.

The answer is yes, no, maybe. Why?

In practice there are limitations, both on the hardware side and on the
kernel side.

The kernel limits the max. APIC ID to 32768 and the maximum number of
CPUs to 8192 right now. Increasing the maximum APIC ID is possible, but
that needs some deep thoughts as we have one array which is
MAX_LOCAL_APIC sized and a bitmap of that size too. Even the bitmap
would require (1 << 32)/8 = 5.36871e+08 B = 512MB of memory. With a limit
of 32768 it's a reasonable 4KB. :)

On the hardware side the topology information is in the APIC ID:

      [PKGID][DIEID]...[COREID][THREADID]

where everything below the PKGID is relative to the package. Right now
the vendors have that space packed, i.e. the number of bits below PKGID
is sized that its the next power of 2 which allows to fit the actual
number of logical processors.

There have been systems where the PKGID shift was larger than that which
caused us to do the logical package mapping because we ended up with
package ID gaps. That was caused by incorrect information in leaf
0xB/0x1F, i.e. the package shift enumerated was smaller than the actual
one.

So with an upper limit of 8192 CPUs the limitation to 32K APIC IDs
should be really sufficient. The largest package shift I've seen so far
is 8, i.e. 256 logical processors per package. That means 32 packages
max. That should be sufficient for a while, right? The HPE/UV people
might have a word to say here though.

So no, u16 is fine, but yes, we can make it u32 just for simplicity
sake, which still does not allow you to have an APIC ID >= 32k, but
makes it easy enough to expand that to e.g. 64K or 128K if the need ever
arises. Let me rework that accordingly.

Thanks,

        tglx