On Thu, Jan 17, 2013 at 04:20:15PM +0100, Peter Krempa wrote: > On 01/17/13 15:48, Daniel P. Berrange wrote: > >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. > > Okay, this is fair enough and might work even for non-symetric > multiprocessor systems. > > > > >>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. > > > > I beg to differ: > > "This technology is informally called CMT (Clustered Multi-Thread) > and formally called "module" by the AMD's marketing service, but > whose real name is "Clustered Integer" Core Technology. In terms of > hardware complexity and functionality, this "module" is midway > between a true dual-core processor and its integer power (each > thread having a fully independent integer core) and a single core > processor that has the SMT ability, which can create a dual threads > processor but with the power of one (each thread shares the > resources of the core with the other thread)." > > (source: http://en.wikipedia.org/wiki/Bulldozer_(microarchitecture)#BULLDOZER_Core_.28aka_Module.29 > ) > > oVirt/vdsm considers the "Module" as a core with two threads, where > others consider it more as separate cores. The performance depends > on the type of task that is being run on the module. So what information does VDSM use to identify this hardware topology. In some form or another we need to be providing the more detailed and accurate topology infomation in the capabilities NUMA description. What does 'hwloc --no-io --no-caches' shown on a Bulldozer machine ? 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