On Tue, Feb 06, 2024 at 07:04:30PM +0100, Andrea Bolognani wrote: > I've seen examples in the wild of the cluster attribute having > non-zero value on x86_64. > > This is obviously quite confusing, but it's the information that > Linux exposes to userspace and we don't really have a way to tell > apart a valid die/cluster ID from a dummy one. > > What ultimately matters is that the underlying assumptions about > topology are respected, which they are: in the x86_64 cases that > I have analyzed, for example, each "cluster" contained exactly > one core, so any program that would use this information to > influence guest topology decisions would be unaffected by the > additional level showing up in the hierarchy. > > In an attempt to reduce confusion, document that the value for > these attributes is not necessarily going to be zero. > > Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> > --- > docs/formatcaps.rst | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst > index f37532296f..c15d391b63 100644 > --- a/docs/formatcaps.rst > +++ b/docs/formatcaps.rst > @@ -74,14 +74,18 @@ The ``<host/>`` element consists of the following child elements: > ``die_id`` > Identifier for the die the CPU is in. > > - Note that not all architectures support CPU dies: if the current > - architecture doesn't, the value will be 0 for all CPUs. > + Note that, while not all architectures support CPU dies, this attribute > + will always be present in the capabilities XML. If the architecture > + doesn't support them, the value will likely be 0 for all CPUs, but it > + could also be some other arbitrary value. I would remove the caveat about "not all architectures support CPU dies" entirely, and about special die id values. I tend to say that every CPU every manufactured supports "dies", but that most CPUs dont support more than 1 die :-) The purpose of exposing this info is primarily to help apps / admins in placing guests, and matching host / guest topology where applicable. To do that they don't need to care if a CPU supports more than 1 die or not, they just need to see the topology reported. If they do want to detect >1 die for some reason though, they should not try to look for special 'die_id' values, instead look to see if there are more than 1 *distinct* die_id within a single socket_id. > > ``cluster_id`` > Identifier for the cluster the CPU is in. > > - Note that not all architectures support CPU clusters: if the current > - architecture doesn't, the value will be 0 for all CPUs. > + Note that, while not all architectures support CPU clusters, this > + attribute will always be present in the capabilities XML. If the > + architecture doesn't support them, the value will likely be 0 for all > + CPUs, but it could also be some other arbitrary value. Same comment as above. > > ``core_id`` > Identifier for the core the CPU is in. > -- > 2.43.0 > _______________________________________________ > Devel mailing list -- devel@xxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
