<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/16/2013 04:30 PM, Daniel P.
Berrange wrote:<br>
</div>
<blockquote cite="mid:20130116193017.GX3255@redhat.com" type="cite">
<pre wrap="">On Wed, Jan 16, 2013 at 02:15:37PM -0500, Peter Krempa wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
----- Original Message -----
From: Daniel P. Berrange <a class="moz-txt-link-rfc2396E" href="mailto:berrange@redhat.com"><berrange@redhat.com></a>
To: Peter Krempa <a class="moz-txt-link-rfc2396E" href="mailto:pkrempa@redhat.com"><pkrempa@redhat.com></a>
Cc: Jiri Denemark <a class="moz-txt-link-rfc2396E" href="mailto:jdenemar@redhat.com"><jdenemar@redhat.com></a>, Amador Pahim <a class="moz-txt-link-rfc2396E" href="mailto:apahim@redhat.com"><apahim@redhat.com></a>, <a class="moz-txt-link-abbreviated" href="mailto:libvirt-list@redhat.com">libvirt-list@redhat.com</a>, <a class="moz-txt-link-abbreviated" href="mailto:dougsland@redhat.com">dougsland@redhat.com</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">On 01/16/13 19:11, Daniel P. Berrange wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, Jan 16, 2013 at 05:28:57PM +0100, Peter Krempa wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
I'm too somewhat concerned about changing this output due to
historic reasons.
</pre>
<blockquote type="cite">
<pre wrap="">
Apps should be using the separate NUMA <topology> data in the capabilities
instead of the CPU <topology> data, to get accurate CPU counts.
</pre>
</blockquote>
<pre wrap="">
>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.
</pre>
</blockquote>
<pre wrap="">
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>.
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">In this case, we will also need to add the thread siblings and
perhaps even core siblings information to allow reliable detection.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
Not true to AMD
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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.
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</body>
</html>