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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list