Messages in this thread | | | Date | Wed, 20 Sep 2023 08:51:03 +0530 | Subject | Re: [patch V4 24/41] x86/cpu: Provide cpu_init/parse_topology() | From | K Prateek Nayak <> |
| |
Hello Arjan,
On 9/19/2023 7:14 PM, Arjan van de Ven wrote: > >>>>> specifically "... combining up to four Intel 7-built tiles on a single >>>>> package, connected using Intel EMIB ...". Perhaps the one from Qiuxu >>>>> Zhuo's report does not contain multiple tiles. >>>> >>>> I think what Arjan was saying that despite them being build using >>>> multipe physical tiles, they describe themselves, in the topology leave, >>>> as being a single tile. >>> >>> and more than that -- from a software perspective, they truely act as if they are 1 tile >> >> If possible, can you please elaborate on the "software perspective". Say >> CPUID leaf 0x1f reports multiple tile, would the data access latency or >> cache to cache latency see a noticeable difference? > > no. (not on SPR unless you turn on SNC, which is a whole different world) > >> >> I would like to understand what the characteristics of a "Tile" are and >> whether they are similar to AMD's CCX instances discoverable by AMD's >> extended CPUID leaf 0x80000026. That way, in future, when the generic >> topology is used by other subsystems, the data from "TOPO_TILE_DOMAIN" >> can be used generically for both Intel and AMD. > > SPR for all intents and purposes for software does not have tiles. So please > lets not design for that ;-) > > The reality is that we really should not hardcode topology things to cache things. > Sure today tile is an L3 boundary for AMD, and on all no-tile systems by construction > of the topology tree. > But maybe some smart person in AMD decides > that for a next generation, it's faster to split the L3 in half -- or to make that > extra HBM-like cache span 2 tiles or .. or .. > > CPUID enumerates cache domains pretty much separate and that;s a good thing. > We absolutely need a "cache view" of the system, but that is a mapping to topology, > not hardcoded in topology (so one level of indirection + of course cached/computed > bitmaps etc for cheap access) > > Makes sense! I think that is the reason we have Cache Identifiers in the first place. I'm satisfied with the explanation from Thomas (https://lore.kernel.org/lkml/87y1h2wpfw.ffs@tglx/) as long as their use in the future, in generic code, does not assume any characteristics that is not generic to the whole of x86 :)
-- Thanks and Regards, Prateek
| |