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. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list