On Wed, Jan 13, 2016 at 12:15:23PM -0500, John Ferlan wrote: > > > 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. You can't assume that the different controllers are independant, though on most systems they will be. The default systemd layout creates a separate mount for each controler under /sys/fs/cgroup/$controller, but it is valid to create a single mount point to hold *all* controllers. In such a case, if you move placement for 'cpu' controller it will affect *all* controllers. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list