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

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?