Re: [libvirt] [PATCH 0/3] several cgroups/cpuset fixes

>> >> I'm leaning towards something in the test. I'll check if reverting >> these changes alters the results. I don't imagine it will. > > The real question is which thread it fails on and at what point in > time. My patches only changed the order of operations where threads > enter the cpuset cgroups at a slightly different time. And the qemu > main thread never enters the parent group, it becomes an > emulator-thread. Maybe you can point to exactly the assertion that > fails. Including a link to the test code. And yes if you can > confirm that the patches are to blame that would be a good first > step ;). > > Thanks, > Henning > Update: I have found that if I revert patch 2... Then modify qemuInitCgroup() to modify the virCgroupNewMachine check to also ensure "|| !priv->cgroup)

Then modify qemuSetupCgroupForEmulator() to make the virCgroupAddTask() call like was in patch 2 Then modify patch 3 (qemuSetupCgroupForVcpu) to change the call: if (!cpumap) continue; if (qemuSetupCgroupCpusetCpus(cgroup_vcpu, cpumap) < 0) goto cleanup; to if (cpumap && qemuSetupCgroupCpusetCpus(cgroup_vcpu, cpumap) < 0) goto cleanup;

Then retest and the test passes again. Note that taking this route, I found that when I start the guest, I have the following in 'tasks': # cat /sys/fs/cgroup/memory/machine.slice/tasks # cat /sys/fs/cgroup/memory/machine.slice/*/tasks 15007 15008 15010 15011 15013 # Where '15007' is the virt-tests-vm1 process (eg, /proc/$pid/cgroup). If I read the intentions you had, this follows that... I'll post a couple of patches in a bit... John