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/ :|