On 01/17/13 10:36, Daniel P. Berrange wrote:
Well not for all machines in the wild out there. This is a very
similar approach that libvirt uses now to detect the topology and it
is not enough to detect threads on AMD Bulldozer as the cpus
corresponding to the threads have different core_id's (they are also
considered as cores from the perspective of the kernel). This is
unfortunate for the virtualization management tools as oVirt that
still consider the AMD Bulldozer "module" as a 1 core with two
threads, even if it registers as two cores.
For AMD Bulldozer to be detected correctly, we would need to expose
the thread_id's along with thread siblings information to determine
the two threads belonging together.
NB, the socket_id / core_id values in the above XML are *not* intended
to be anyway related to similarly named values in /proc/cpuinfo. They
are values libvirt assigns to show the topology accurately.
Hm, in that case I'm not sure if it's worth bothering with detecting the
topology, then (possibly) making up the data provided in the XML. The
management applications then will have to calculate the topology from
our data again just to know the topology. For other possible uses of the
data the management app would still need to re-detect it on their own if
they need (for some reason) the actual data.
Also, even with non-real data in these fields here it won't enable us to
reflect the topology of AMD Bulldozer reliably. We would have to choose
whether we'd like to report the modules as cores or threads. And each of
these choices will possibly make someone complain that they don't like
the choice.
Peter
Daniel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
