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

Amador Pahim apahim at redhat.com
Wed Jan 16 20:06:21 UTC 2013


On 01/16/2013 04:30 PM, Daniel P. Berrange wrote:
> On Wed, Jan 16, 2013 at 02:15:37PM -0500, Peter Krempa wrote:
>> ----- Original Message -----
>> From: Daniel P. Berrange <berrange at redhat.com>
>> To: Peter Krempa <pkrempa at redhat.com>
>> Cc: Jiri Denemark <jdenemar at redhat.com>, Amador Pahim <apahim at redhat.com>, libvirt-list at redhat.com, dougsland at 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.

Not true to AMD Magny-Cours 6100 series, where different cores can share 
the same physical_id and core_id. And they are not threads. This 
processors has two numa nodes inside the same "package" (aka socket) and 
they shares the same core ID set. Annoying.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130116/b212a8c4/attachment-0001.htm>


More information about the libvir-list mailing list