Re: [libvirt] [REPOST 0/4] Adjustment to recent cgroup/cpuset changes (for 1.3.1)

On 01/13/2016 11:51 AM, Martin Kletzander wrote: > On Wed, Jan 13, 2016 at 07:29:46AM -0500, John Ferlan wrote: >> Reposting my cgroup fixes series: >> >> http://www.redhat.com/archives/libvir-list/2016-January/msg00236.html >> >> partially because I originally forgot to CC the author (Henning Schild) >> of the original series for which these patch fix a couple of issues >> discovered during regression testing (virt-test memtune failures in >> Red Hat regression environment), but also to bring them up to date >> with the top of libvirt git. >> >> NB: I did send Henning the changes after the fact, but my resend using >> the same message-id skills so that replies are left in the onlist series >> are lacking. Henning has looked at the first patch - with a response >> here: >> >> http://www.redhat.com/archives/libvir-list/2016-January/msg00443.html >> >> Finally, I think these changes should go into 1.3.1 since that's when the >> regression was introduced. >> > > It would be nice to have them in, I really tried reviewing them, but I > can't wrap my head around last two of them. Maybe because I'm already > late for an appointment I have. > What I found happening is that by moving the virCgroupAddTask from qemuInitCgroup until later in qemuSetupCgroupForEmulator is that for "some reason" on (at least in the test environment) an older Fedora release (f20) that the /proc/$pid/cgroup file was updated "strangely". On a more recent Fedora release (f23) I didn't see the same phenomena. And by strangely - what I saw was even though the *SetupEmulator path was 'supposed to be' modifying only cpuset and cpu,cpuacct - other entries for memory, blkio, and devices were also updated - thus pointing at the wrong place (rather than the machine specific place). This caused the memtune test to fail. What was even stranger is that the code was updating the machine specific area when changing the values (e.g., internally we had the right path), but the test cannot see that so it uses the /proc/$pid/cgroup file to find the path.