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

[Arjan van de Ven]

> > > > 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)