Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
The AMD Bulldozer architecture consists of "modules" which are reported by the kernel as both threads and cores. Libvirt's processor topology detection code wasn't able to detect this properly thus libvirt reported twice the actual number of processors.
This issue was fixed by reporting a topology that adds up to the total number of processors reported in the system but the actual topology has to be checked in output of virCapabilities() (virsh capabilities). Also the fallback output was documented.
Additionally the users should be instructed to use the capability output for topology detection purposes due to performance reasons. NUMA topology has the important impact performance-wise but the physical topology can differ from that.
Fixed upstream:
commit 7a791677b0e6cc3ae45aafdbca732f0f7ce05cbf
Author: Peter Krempa <pkrempa>
Date: Wed Nov 7 15:50:56 2012 +0100
nodeinfotest: Add test data from a AMD bulldozer machine.
The AMD Bulldozer architecture uses so called "Clustered integer core
modules" that count both as threads and cores. This patch expects the
cpu to be detected using the new fallback condition otherwise twice the
number of processors would be detected.
commit 86748976f18423c359e94294bd57df9fd9d98ce4
Author: Peter Krempa <pkrempa>
Date: Wed Nov 7 15:19:47 2012 +0100
nodeinfotest: Add test data for 2 processor host with broken NUMA
This test data was gathered on an AMD MagnyCours machine that reports it
has only one NUMA node although the hardware is consisting of 4. As
duplicate core id's are ignored the reported topology was bogous. This
should be fixed by the previous patch.
Reported and data provided by George-Cristian Bîrzan.
commit 9576afd110b8c3edeb65f9b39448884763ca68bd
Author: Peter Krempa <pkrempa>
Date: Wed Nov 7 14:53:36 2012 +0100
nodeinfo: Add check and workaround to guarantee valid cpu topologies
Lately there were a few reports of the output of the virsh nodeinfo
command being inaccurate. This patch tries to avoid that by checking if
the topology actually makes sense. If it doesn't we then report a
synthetic topology that indicates to the user that the host capabilities
should be checked for the actual topology.
# rpm -q libvirt qemu-kvm kernel
libvirt-0.10.2-9.el6.x86_64
qemu-kvm-0.12.1.2-2.295.el6.x86_64
kernel-2.6.32-279.el6.x86_64
On the same box as in description:
# virsh nodeinfo
CPU model: x86_64
CPU(s): 64
CPU frequency: 2593 MHz
CPU socket(s): 1
Core(s) per socket: 64
Thread(s) per core: 1
NUMA cell(s): 1
Memory size: 132101788 KiB
I did not do detail check of all the patches yet, but nodeinfo still fail to show the right info. Threads per core might be right now, but host is 8 nodes not 1, and cores per socket should be 8 not 64 as i think.
Hi Peter, What you think?
In case of unusual NUMA machines where we can't accurately detect the topology of the processor the data reported in the virNodeInfo structure is modified to correctly report the maximum number of processors in the host. The modification is done according to this documentation:
nodes: the number of NUMA cell, 1 for unusual NUMA topologies or uniform memory access; check capabilities XML for the actual NUMA topology
sockets: number of CPU sockets per node if nodes > 1, 1 in case of unusual NUMA topology
cores: number of cores per socket, total number of processors in case of unusual NUMA topology
threads: number of threads per core, 1 in case of unusual numa topology
Since patches in comment #7 is not included, no check on them. Peter emphasise what nodeinfo will act on unusual NUMA machines in comment #10, so the result in comment #9 is expected now.
So, this is fixed. Also test on 1 usual NUMA box and an non-NUMA box, works fine.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHSA-2013-0276.html