On Tue, Oct 30, 2012 at 10:08 PM, Eric Blake <[email protected]> wrote:
> Both bitmaps show all 24 cores, so hwloc is able to read sysfs and > determine the existence of 2 sockets with 12 nodes each, and where the > 12 nodes are numbered 0-5 twice according to which bank of cache they > are tied to. Which version of libvirt is this tested on where libvirt > was only reporting 12 cores, because I thought we already patched that > with commit 80533ca in 0.10.0. That is, I think proc1.png should result > in: > > $ virsh nodeinfo > CPU model: x86_64 > CPU(s): 24 > CPU frequency: 2200 MHz > CPU socket(s): 2 > Core(s) per socket: 12 > Thread(s) per core: 1 > NUMA cell(s): 1 > Memory size: 8047272 KiB > > (Just for clarity, I am the original reporter, sorry I couldn't answer earlier, I subscribed to the list too late and didn't want to break the thread) On the host with 1 NUMA cell, with libvrit 0.10.2 I get: [root@host29 ~]# virsh nodeinfo CPU model: x86_64 CPU(s): 24 CPU frequency: 2200 MHz CPU socket(s): 2 Core(s) per socket: 6 Thread(s) per core: 1 NUMA cell(s): 1 Memory size: 131971548 KiB Furthermore, to answer the question at the bottom of your email, http://birzan.org/capabilities1.txt has this info. > and proc4.png would _ideally_ result in: > > $ virsh nodeinfo > CPU model: x86_64 > CPU(s): 24 > CPU frequency: 2200 MHz > CPU socket(s): 2 > Core(s) per socket: 12 > Thread(s) per core: 1 > NUMA cell(s): 4 > Memory size: 8047272 KiB > > [root@host34 ~]# virsh nodeinfo CPU model: x86_64 CPU(s): 24 CPU frequency: 2200 MHz CPU socket(s): 2 Core(s) per socket: 6 Thread(s) per core: 1 NUMA cell(s): 1 Memory size: 131971020 kB And http://birzan.org/capabilities4.txt This is on 0.9.11.5, on 0.10.2: [root@host34 libvirt]# virsh nodeinfo CPU model: x86_64 CPU(s): 24 CPU frequency: 2200 MHz CPU socket(s): 1 Core(s) per socket: 6 Thread(s) per core: 1 NUMA cell(s): 4 Memory size: 131971020 KiB and http://birzan.org/capabilities4-newlibvirt.txt This has made the problem even worse, as we now can only use 6 cores out of 24 by default (libvirt pins qemus to the CPUs is sees available, so we have to manually taskset them after starting). > I think the CPU _is_ reporting the complete NUMA topology through sysfs, > but that we are probably consolidating information from the wrong files > and therefore getting confused. > > The sysfs is tarred up in http://birzan.org/sysdevicessystem.tar.gz for host29 (the one with 1 numa cell in capabilities) and http://birzan.org/sysdevicessystem-34.tar.gz > Also, what does the 'virsh capabilities' report for the <topology> > section? Whereas 'virsh nodeinfo' is constrained by back-compat to give > a lame answer for number of NUMA cells, at least 'virsh capabilities' > should be showing a reasonable representation of the machine's topology. > > I answered this above. If you need any more info, feel free to ask. -- George-Cristian Bîrzan
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
