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.
The kernel is also using an ambiguous description where the core ID's of
the two threads of a module are different and also the thread siblings
field is filled out targeting each other.
Peter
Daniel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
