On Fri, May 11, 2012 at 10:28:21PM +0800, Osier Yang wrote: > "Instead of developing one CPU with 12 cores, the Magny Cours is > actually two 6 core “Bulldozer” CPUs combined in to one package" > > I.e, each package has two NUMA nodes, and the two numa nodes share > the same core ID set (0-6), which means parsing the cores number > from sysfs doesn't work in this case. > > And the wrong CPU number could cause three problems for libvirt: > > 1) performance lost > > A domain without "cpuset" or "placement='auto'" (to drive numad) > specified will be only pinned to part of the CPUs. > > 2) domain can be started > > If a domain uses numad, and the advisory nodeset returned from > numad contains node which exceeds the range of wrong total CPU > number. The domain will fail to start, as the bitmask passed to > sched_setaffinity could be fully filled with zero. > > 3) wrong CPU number affects lots of stuffs. > > E.g. for command "virsh vcpuinfo", "virsh vcpupin", it will always > output with the truncated CPU list. > > For more details: > > https://www.redhat.com/archives/libvir-list/2012-May/msg00607.html > > This patch is to fix the problem by parsing /proc/cpuinfo to get > the value of field "cpu cores", and use it as nodeinfo->cores if > it's greater than the cores number from sysfs. > --- > src/nodeinfo.c | 28 ++++++++++++++++++++++++++++ > 1 files changed, 28 insertions(+), 0 deletions(-)
Given how complex (and frequently broken) this CPU info parsing is, I really think this change needs to be accompanied by improvements to our test suite. IIUC, we can easily test this by including copies of the /proc/cpuinfo from a variety of different machines in our tests directory and running the APIs against that. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
