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

[...] >> No problem - although it seems they've generated a regression in >> the virttest memtune test suite. I'm 'technically' on vacation >> for the next couple of weeks; however, I think/perhaps the problem >> is a result of this patch and the change to adding the task to the >> cgroup at the end of the for loop, but perhaps the following code >> causes the control to jump back to the top of the loop: >> >> if (!cpumap) >> continue; >> >> if (qemuSetupCgroupCpusetCpus(cgroup_vcpu, cpumap) < >> 0) goto cleanup; >> >> not allowing the >> >> >> /* move the thread for vcpu to sub dir */ >> if (virCgroupAddTask(cgroup_vcpu, >> qemuDomainGetVcpuPid(vm, i)) < 0) >> goto cleanup; >> >> to be executed. >> >> The code should probably change to be (like IOThreads): >> >> if (cpumap && >> qemuSetupCgroupCpusetCpus(cgroup_vcpu, cpumap) < >> 0) goto cleanup; >> >> >> As for the rest, I suspect things will be quite quiet around here >> over the next couple of weeks. A discussion to perhaps start in >> the new year. > > Same here. I will have a look at that regression after my vacation, > should it still be there. > > Henning > More data from the issue... While the above mentioned path is an issue, I don't believe it's what's causing the test failure. I haven't quite figured out why yet, but it seems the /proc/#/cgroup file isn't getting the proper path for the 'memory' slice and thus the test fails because it's looking at the: /sys/fs/cgroup/memory/machine.slice/memory.* files instead of the /sys/fs/cgroup/memory/machine.slice/$path/memory.*

Where $path is "machine-qemu\x2dvirt\x2dtests\x2dvm1.scope" This affects the virsh memtune $dom command test suite which uses the /proc/$pid/cgroup file in order to find the path for the 'memory' or 'cpuset' or 'cpu,cpuacct' cgroup paths. Seems to be some interaction with systemd that I have quite figured out. I'm assuming this is essentially the issue you were trying to fix - that is changes to values should be done to the machine-qemu* specific files rather than the machine.slice files. The good news is I can see the changes occurring in the machine-qemu* specific files, so it seems libvirt is doing the right thing. However, there's something strange with perhaps previously existing/running domains where that /proc/$pid/cgroup file doesn't get the $path for the memory entry, thus causing the test validation to look in the wrong place. Hopefully this makes sense. What's really strange (for me at least) is that it's only occurring on one test system. I can set up the same test on another system and things work just fine. I'm not quite sure what interaction generates that /proc/$pid/cgroup file - hopefully someone else understands it and help me make sense of it.