> >> The current kernel doesn't have sensitivity to a level between L3 boundary > >> and > >> socket. Also, most production systems in current AMD CPU landscape have > >> CCD=CCX. > >> Only a handful of models feature CCD=2CCX, so this isn't an immediate > >> pressing need. > >> > >> In QEMU's terminology, socket represents an actual socket and die > >> represents the > >> L3 cache boundary. There is no intermediate level between them. Looking > >> ahead, > >> when more granular topology information (like CCD) becomes necessary for > >> VMs, > >> introducing a "diegroup" level would be the logical approach. This level > >> would > >> fit naturally between die and socket, as its role cannot be fulfilled by > >> existing topology levels. > > > > With your nice clarification, I think this problem has become a bit easier. > > > > In fact, we can consider that CCD=CCX=die is currently the default > > assumption in QEMU. When future implementations require distinguishing > > between > > these CCD/CCX concepts, we can simply introduce an additional "smp.tiles" > > and > > map CCX to it. This may need a documentation or a compatibility option, but > > I > > believe these extra efforts are worthwhile. > > > > And "smp.tiles" means "how many tiles in a die", so I feel it's perfect > > to describe CCX. > > That indeed looks like a cleaner solution. However, I'm concerned about > retaining compatibility with existing "dies". But yeah, that's a task for a > later time.
Yes, it may be necessary to address some compatibility issues. But I think this way could align with the topology mapping of the Linux kernel as much as possible. Thanks, Zhao
