[libvirt] [Resending][PATCH v2 2/2] x86: Allow sysinfo to fall back on /proc/cpuinfo if demidecode is absent
Prerna Saxena
prerna at linux.vnet.ibm.com
Thu Mar 15 06:58:05 UTC 2012
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.
>>
>> On 03/14/2012 02:29 PM, Daniel Veillard wrote:
>>> On Tue, Mar 13, 2012 at 11:10:16AM +0530, Prerna Saxena wrote:
>>>> From: Prerna Saxena <prerna at linux.vnet.ibm.com>
>>>> Date: Tue, 13 Mar 2012 15:33:43 +0530
>>>> Subject: [PATCH 2/2] Sysinfo : Allow x86 to fetch sysinfo from
>>>> /proc/cpuinfo in the event 'dmidecode' is absent in the system.
>>>>
>>>> Until now, libvirt on x86 flags an error message if dmidecode is not
>>>> found. With this patch, the following is a sample output on x86 when
>>>> dmidecode is absent:
>>>>
>>>> virsh # sysinfo
>>>> <sysinfo type='smbios'>
>>>> <processor>
>>>> <entry name='socket_destination'>0</entry>
>>>> <entry name='type'>Intel(R) Xeon(R) CPU X5570 @ 2.93GHz</entry>
>>>> <entry name='family'>6</entry>
>>>> <entry name='manufacturer'>GenuineIntel</entry>
>>>> </processor>
>>>> <processor>
>>>> <entry name='socket_destination'>1</entry>
>>>> <entry name='type'>Intel(R) Xeon(R) CPU X5570 @ 2.93GHz</entry>
>>>> <entry name='family'>6</entry>
>>>> <entry name='manufacturer'>GenuineIntel</entry>
>>>> </processor>
>>>> ... (listing for all online CPUs)
>>>> </sysinfo>
>>>>
>>>> Based on suggestion from Eric:
>>>> (http://www.redhat.com/archives/libvir-list/2012-February/msg00509.html)
>>>>
>>>> Acked-by: Daniel P Berrange <berrange at redhat.com>
>>>> Signed-off-by: Prerna Saxena <prerna at linux.vnet.ibm.com>
>>>> ---
>>>> src/util/sysinfo.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++--
>>>> 1 files changed, 93 insertions(+), 4 deletions(-)
>>>>
>>>> ... [snip]..
>>>
>>> Hi Prerna,
>>>
>>> that sounds like a good idea, and the patch seems to work but I have
>>> doubt with the usefulness in its current form. Let me explain:
>>>
>>> with dmidecode available on my system I get:
>>>
>>> ...
>>> <processor>
>>> <entry name='socket_destination'>Socket 775</entry>
>>> <entry name='type'>Central Processor</entry>
>>> <entry name='family'>Other</entry>
>>> <entry name='manufacturer'>Intel</entry>
>>> <entry name='signature'>Type 0, Family 6, Model 15, Stepping
>>> 11</entry>
>>> <entry name='version'>Intel(R) Core(TM)2 Duo CPU E6550 @
>>> 2.33GHz</entry>
>>> <entry name='external_clock'>333 MHz</entry>
>>> <entry name='max_speed'>4000 MHz</entry>
>>> <entry name='status'>Populated, Enabled</entry>
>>> </processor>
>>> ...
>>>
>>> without dmidecode and your patch plugged in I get
>>>
>>> <processor>
>>> <entry name='socket_destination'>0</entry>
>>> <entry name='type'>Intel(R) Core(TM)2 Duo CPU E6550 @
>>> 2.33GHz</entry>
>>> <entry name='family'>6</entry>
>>> <entry name='manufacturer'>GenuineIntel</entry>
>>> </processor>
>>> <processor>
>>> <entry name='socket_destination'>1</entry>
>>> <entry name='type'>Intel(R) Core(TM)2 Duo CPU E6550 @
>>> 2.33GHz</entry>
>>> <entry name='family'>6</entry>
>>> <entry name='manufacturer'>GenuineIntel</entry>
>>> </processor>
>>>
>>> so basically we get informations, some are available in both case but
>>> differently, and worse, in the fallback case we get 2 physical processor
>>> entries (I have only one) which is of course different from the single
>>> processor that we get with dmidecode.
>>>
>>> So 1/ is seems to me the fallback data can't be parsed
>>> programmatically as a replacement of the original ones
>>> 2/ the data may be misunderstood and lead to erroneous
>>> decision for example a schedule may start to stack 2 time more
>>> load on my machine based on the difference of report.
>>>
>>> So I'm a bit worried about applying it as-is, I'm afraid we need
>>> to reconcile the output (as much as possible considering there
>>> is less data) between both cases.
>>>
>>
>> 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?
>>
>>> That said I think patch 1/2 looks fine to me, and could probably be
>>> applied as-is,
>>>
>>
>> Thanks! Would you want to apply it as-is, or shall I send a rebased
>> version ?
>
> Well if you're fixing 2/2 before end of next week, I suggest to apply
> both together and hence rebase 1/2 when you submit 2/2 v3 :)
>
> Daniel
>
Regards,
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
More information about the libvir-list
mailing list