[CRIU] [PATCH 1/2] cg: Add ability to dump custom cgroup properties and skip controllers
Tycho Andersen
tycho.andersen at canonical.com
Wed Apr 27 07:44:17 PDT 2016
On Wed, Apr 27, 2016 at 05:36:35PM +0300, Cyrill Gorcunov wrote:
> On Wed, Apr 27, 2016 at 08:30:10AM -0600, Tycho Andersen wrote:
> > Hi Cyrill,
> >
> > On Wed, Apr 27, 2016 at 11:53:09AM +0300, Cyrill Gorcunov wrote:
> > > +
> > > + if (!list_empty(&cgp_list)) {
> > > + pr_info("Custom controllers defined. Zapping compiled in ones.\n");
> > > + INIT_LIST_HEAD(&cgp_predefined_list);
> > > + }
> >
> > This means that (IIUC) we can't inherit some properties from the built
> > in set. The way I envision using this feature is for when new
>
> Yes, once new specified in command line it means built-ins are
> zapped out, so that we have to provide complete set of controllers
> and properties in specification.
>
> > controllers or properties are released in the kernel but not in
> > upstream CRIU yet (because I haven't updated the list ;-), so I'd
> > probably want all the built in ones plus some additional ones.
>
> I don't mind. We will need to provide strategy argument then,
> probably inside specification?
Potentially, or just a --cgroup-no-defaults or
--cgroup-include-defaults switch would be fine with me.
> > Is there some way we can either add a mode to merge the props provided
> > into the props hardcoded? We could just merge by controller, so if you
> > specify some props for a controller, you have to specify all the ones
> > for that controller, but if you don't say anything about a controller,
> > you get the defaults (or you can exclude it with
> > --cgroup-exclude-controller when that patch lands).
>
> I'm all opening for suggestion. While not merged we can easily
> try out various approaches.
More information about the CRIU
mailing list