[CRIU] [PATCH 1/2] cgroups: Add ability to reuse precreated controllers and cgroups
Cyrill Gorcunov
gorcunov at gmail.com
Fri May 22 05:03:46 PDT 2015
On Fri, May 22, 2015 at 02:53:22PM +0300, Pavel Emelyanov wrote:
> On 05/21/2015 10:33 PM, Cyrill Gorcunov wrote:
> > When been playing wich checkpoint/restore of container I found
> > that we can't reuse existing controller if they were pre-created.
> > For example currently in PCS7 we're bindmount cgroups which belong
> > to a container in a form of
> >
> > /sys/fs/cgroup/<controller>/<container> ==> /sys/fs/cgroup/<controller>
> >
> > so that CRIU dumps such configuration fine but on restore
> > it recreates controllers from the scratch which we would
> > like to bindmount them and ask CRIU to restore subcgroups
> > and their parameters.
> >
> > So I extended --manage-cgroups option to take <mode> arguments
> > which might be
> >
> > - strict: default mode -- no change in current behaviour,
> > we restore everything from the scratch failing with error
> > if some toplevel controller or cgroup already exist
>
> What do you mean by "default"? The mode when --mange-cgroups is
> specified, but "mode" (argument) is not?
Yes. To keep backward compatibility.
>
> > - opport: opportunistic mode -- if controller or toplevel
> > cgroup doesn't exist we create it, otherwise simply continue
> > execution. iow here we try to continue as long as we can.
> >
> > - bind: bindmount mode -- implies that controller and toplevel
> > cgroup must already exist.
> >
> > The last mode allows me to premount cgroups for container externally
> > and restore its limits from CRIU.
>
> I see that modes can be OR-ed. What do the combinations mean?
At the momen it doesn't do anything useful, because there are
only plain tests when we're handling cgroups (ie most relaxed
mode is tested first). But I think we might extend the semantics
in future that's where OR came from.
More information about the CRIU
mailing list