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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list