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