Re: [RFC] Data in the <topology> element in the capabilities XML

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]