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@xxxxxxxxxxxxxxxxxx> >>>> 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@xxxxxxxxxx> >>>> Signed-off-by: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx> >>>> --- >>>> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list