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

[Daniel P. Berrange]

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