On Wed, Jan 16, 2013 at 02:15:37PM -0500, Peter Krempa wrote: > > ----- Original Message ----- > From: Daniel P. Berrange <berrange@xxxxxxxxxx> > To: Peter Krempa <pkrempa@xxxxxxxxxx> > Cc: Jiri Denemark <jdenemar@xxxxxxxxxx>, Amador Pahim <apahim@xxxxxxxxxx>, libvirt-list@xxxxxxxxxx, dougsland@xxxxxxxxxx > Sent: Wed, 16 Jan 2013 13:39:28 -0500 (EST) > Subject: Re: [RFC] Data in the <topology> element in the capabilities XML > > On Wed, Jan 16, 2013 at 07:31:02PM +0100, Peter Krempa wrote: > > On 01/16/13 19:11, Daniel P. Berrange wrote: > > >On Wed, Jan 16, 2013 at 05:28:57PM +0100, Peter Krempa wrote: > > >>Hi everybody, > > >> > > >>a while ago there was a discussion about changing the data that is > > >>returned in the <topology> sub-element: > > >> > > >><capabilities> > > >> <host> > > >> <cpu> > > >> <arch>x86_64</arch> > > >> <model>SandyBridge</model> > > >> <vendor>Intel</vendor> > > >> <topology sockets='1' cores='2' threads='2'/> > > >> > > >> > > >>The data provided here is as of today taken from the nodeinfo > > >>detection code and thus is really wrong when the fallback mechanisms > > >>are used. > > >> > > >>To get a useful count, the user has to multiply the data by the > > >>number of NUMA nodes in the host. With the fallback detection code > > >>used for nodeinfo the NUMA node count used to get the CPU count > > >>should be 1 instead of the actual number. > > >> > > >>As Jiri proposed, I think we should change this output to separate > > >>detection code that will not take into account NUMA nodes for this > > >>output and will rather provide data as the "lspci" command does. > > >> > > >>This change will make the data provided by the element standalone > > >>and also usable in guest XMLs to mirror host's topology. > > > > > >Well there are 2 parts which need to be considered here. What do we report > > >in the host capabilities, and how do you configure guest XML. > > > > > > From a historical compatibility pov I don't think we should be changing > > >the host capabilities at all. Simply document that 'sockets' is treated > > >as sockets-per-node everywhere, and that it is wrong in the case of > > >machines where an socket can internally have multiple NUMA nodes. > > > > I'm too somewhat concerned about changing this output due to > > historic reasons. > > > > > >Apps should be using the separate NUMA <topology> data in the capabilities > > >instead of the CPU <topology> data, to get accurate CPU counts. > > > > From the NUMA <topology> the management apps can't tell if the CPU > > is a core or a thread. For example oVirt/VDSM bases the decisions on > > this information. > > Then, we should add information to the NUMA topology XML to indicate > which of the child <cpu> elements are sibling cores or threads. > > Perhaps add a 'socket_id' + 'core_id' attribute to every <cpu>. > In this case, we will also need to add the thread siblings and > perhaps even core siblings information to allow reliable detection. The combination fo core_id/socket_id lets you determine that. If two core have the same socket_id then they are cores or threads within the same socket. If two <cpu> have the same socket_id & core_id then they are threads within the same core. 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