On Wed, May 28, 2014 at 01:44:49PM +0200, Martin Kletzander wrote:
On Wed, May 28, 2014 at 11:29:40AM +0100, Daniel P. Berrange wrote:
On Wed, May 28, 2014 at 11:48:36AM +0200, Martin Kletzander wrote:
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 4818cfb..b77914e 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -17524,7 +17524,7 @@ virDomainDefFormatInternal(virDomainDefPtr def, goto error; } virBufferAsprintf(buf, - "<memnode nodeid='%zu' mode='%s' nodeset='%s'/>\n", + "<memnode cellid='%zu' mode='%s' nodeset='%s'/>\n", i, mode, nodemask); VIR_FREE(nodemask); }
Presumably this belongs in an earlier patch in the series.
Oh, yes :) the fixup was on the wrong line in interactive rebase.
diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index b1bfb5a..ce03a4f 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -588,6 +588,8 @@ qemuSetupCpusetCgroup(virDomainObjPtr vm, if (!virCgroupHasController(priv->cgroup, VIR_CGROUP_CONTROLLER_CPUSET)) return 0;
+ /* ASDF: per-node pinnings are not reflected here */
Are you refering to per-node vCPU pinnings here ?
We already have a per-vCPU pin capability in both the XML and the cgroup setup code and the new <memnode> affinity mask you're adding presumably only applies to memory, not vCPUs, otherwise we'd be effectively having two places to set the same info.
What we are doing now is that we take the nodeset from <memory>, put it into cpuset.mems and do virCgroupCpuSetInherit() for the underlying cgroups in the hierarchy. What we should do is put the right nodeset in each (related memnode or global memory, depending on which ones were set), but *only* if there's mode='strict'. However, I'm not sure how to properly handle both memory and memnode settings with different modes (strict, prefer, interleave).
Oh, so you're thinking that you want to set the memory allocation policy for the vCPU threads to match the <memnode> that the vCPU is associated with. I'm not convinced that is a good idea actually. IMHO <memnode> should only affect the placement of the guest RAM block. I'd class memory allocations done by the vCPU threads as being part of the QEMU global memory pool, so I think I'd expect them to be using <memory> settings not <memnode>. Regards, 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 :|