[libvirt] Problem of host CPU topology parsing

[Osier Yang]

On 2012年05月11日 17:01, Jiri Denemark wrote:
> On Fri, May 11, 2012 at 10:47:06 +0200, Michal Privoznik wrote:
>> On 11.05.2012 10:40, Osier Yang wrote:
>>>      /* nodeinfo->sockets is supposed to be a number of sockets per NUMA
>>> node,
>>>       * however if NUMA nodes are not composed of whole sockets, we just lie
>>>       * about the number of NUMA nodes and force apps to check
>>> capabilities XML
>>>       * for the actual NUMA topology.
>>>       */
>>>      if (nodeinfo->sockets % nodeinfo->nodes == 0)
>>>          nodeinfo->sockets /= nodeinfo->nodes;
>>>      else
>>>          nodeinfo->nodes = 1;
>>>
>>> Jirka said this was for a fix, but I don't quite understand it,
>>> what does the "nodeinfo.nodes" mean actually? Shouldn't it
>>> be 8 (for the 48 CPUs machine) instead? But then we will be
>>> wrong again with using VIR_NODEINFO_MAXCPUS.
>>
>> Why do you think it will be wrong? My understanding is that
>> VIR_NODEINFO_MAXCPUS just tell the max number of possible cpus not the
>> actual. So if it's over 48 we are safe.
>
> Not really, the macro should count exactly the number of CPUs available to
> host, otherwise lots of other issues (incl. backward compatibility) appear. It
> is just a badly named macro that should never exist but we can't do anything
> with it since it is our public API.
>
>> Btw: the code above seems like a hack to me.
>
> Yes, it is a hack but it's unfortunately required because we can't change the
> macro.
>
> Anyway, I agree with Daniel that the bug most likely lies somewhere in the
> code that populates nodeinfo structure.
>
> Jirka

In /proc/cpuinfo:

<snip>
cpu cores       : 12
</snip>

However, there are only 6 core IDs, as showed in
http://fpaste.org/mtoA/. And we parse the core_id
file of each CPU as:

         core = parse_core(cpu);
         if (!CPU_ISSET(core, &core_mask)) {
             CPU_SET(core, &core_mask);
             nodeinfo->cores++;
         }

and thus get only 6 cores. Don't known how 12 in /proc/cpuinfo
is figured out. But could it be a clue?

Regards,
Osier