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

On Wed, Jan 16, 2013 at 02:15:37PM -0500, Peter Krempa wrote: > ----- Original Message ----- > From: Daniel P. Berrange <berrange(a)redhat.com&gt; > To: Peter Krempa <pkrempa(a)redhat.com&gt; > Cc: Jiri Denemark <jdenemar(a)redhat.com&gt;, Amador Pahim <apahim(a)redhat.com&gt;, libvirt-list(a)redhat.com, dougsland(a)redhat.com > Sent: Wed, 16 Jan 2013 13:39:28 -0500 (EST) > Subject: Re: [libvirt] [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.