Re: [patch V4 24/41] x86/cpu: Provide cpu_init/parse_topology()

[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