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

[John Ferlan]

>>
>> 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