On Fri, Nov 25, 2016 at 04:20:18PM +0800, Zhang Zhuoyu wrote: > CPU sockets calculation is inconsistent with physical sockets when > Host machine has more than one node. It only calculate the maximum > socket number of all CPU nodes instead of summing up. > > For example: > > Architecture: x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > CPU(s): 32 > On-line CPU(s) list: 0-31 > Thread(s) per core: 2 > Core(s) per socket: 8 > Socket(s): 2 <------ Host machine has 2 sockets > NUMA node(s): 2 > Vendor ID: GenuineIntel > CPU family: 6 > Model: 62 > Model name: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz > Stepping: 4 > CPU MHz: 3074.296 > BogoMIPS: 5205.76 > Virtualization: VT-x > L1d cache: 32K > L1i cache: 32K > L2 cache: 256K > L3 cache: 20480K > NUMA node0 CPU(s): 0-7,16-23 > NUMA node1 CPU(s): 8-15,24-31 > > CPU model: x86_64 > CPU(s): 32 > CPU frequency: 3021 MHz > CPU socket(s): 1 <----- Should be 2 sockets > Core(s) per socket: 8 > Thread(s) per core: 2 > NUMA cell(s): 2 > Memory size: 131833636 KiB > > "lscpu" shows host machine has 2 sockets, however "virsh nodeinfo" > only calculate the maximum socket number of all CPU nodes, > This patch fix it by summing sockets in all nodes up. No, this is wrong interpretation of the data. 'virsh nodeinfo' is actually reporting sockets *per* NUMA cell. The nodeinfo data is in fact broken if you have a different number of sockets in each cell. So we recommend that apps use the capabilities XML as the accurate socket data. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
