On Thu, Jan 17, 2013 at 03:41:44PM +0100, Peter Krempa wrote:
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.
The point is that libvirt is intended to provide a representation of the data that is independant of the underlying technology. Apps using libvirt can't expect to read /proc/cpuinfo directly and then expect libvirt to match that exactly. They should be using the libvirt APIs/XML for this exclusively & if there is something missing which prevents them doing this, then we need to add it.
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.
I think you're creating a problem where none exists - there is a clear difference between what is a hyperthread vs what is a core, so there is no ambiguity in what we choose to use. We must simply pick the one that is right. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|