[libvirt] [Resending][PATCH v2 2/2] x86: Allow sysinfo to fall back on /proc/cpuinfo if demidecode is absent

[Prerna Saxena]

On 03/15/2012 12:40 PM, Daniel Veillard wrote:
> On Thu, Mar 15, 2012 at 12:28:05PM +0530, Prerna Saxena wrote:
>> On 03/15/2012 11:37 AM, Daniel Veillard wrote:
>>> On Thu, Mar 15, 2012 at 11:21:09AM +0530, Prerna Saxena wrote:
>>>> Hi Daniel,
>>>> Thank you for taking a look.
> [...]
>>>> Thanks for pointing this out. I investigated this discrepancy, and
>>>> discovered that 'dmidecode' presents a listing of processor *cores*.
>>>> However, for /proc/cpuinfo, all hardware threads in a processor show up
>>>> as independent processors. So, while dmidecode correctly reads that my
>>>> system has a single core, /proc/cpuinfo reports two hardware threads in
>>>> the core as two independent logical CPUs.
>>>> To sort this out, one alternative would be to parse the physical_id in
>>>> /proc/cpuinfo -- this would be identical for all logical processors in a
>>>> given core, and thus can be used to report the number of cores in the
>>>> system. Will send a modified patch asap.
>>
>> Hi Daniel,
>> I just realised a correction in the explanation above -- dmidecode only
>> reveals a per-socket listing, while /proc/cpuinfo lists all the physical
>> cores within a socket.
>>
>> So if demidecode lists single entry for a processor, it can be inferred
>> that the machine in question has one socket. /proc/cpuinfo will have
>> listings for each physical core in that socket, plus the hardware
>> threads available.
>>
>> As mentioned earlier, I will be happy to spin a patch that uses
>> 'physical_id' (constant for all cores in a socket) to provide a
>> socket-level information. This will attain parity with 'dmidecode'
>> output and will report *one socket* for such a machine, under the
>> 'processor' XML tag.( Which could be a little misleading)
>>
>> However, I am curious -- what benefit would the number of sockets be to
>> a libvirt user? I expect users would mostly care about number of
>> available CPU cores to take scheduling decisions. Am I missing a
>> use-case for exclusive need of socket-level information?
> 
>   The question at this point is not whether the information is better
> or not, it must be the same in the fallback case. The informations
> won't be missing, it can be gathered by 'virsh nodeinfo' and equivalent
> API. Point of patch 2/2 is to provide some identical informations
> in the case dmidecode is missing.
> 

Okay. I'll send out a v3 of my patch series incorporating changes asap :)

Regards,
-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India