[CRIU] [PATCH 1/2] Re-create cgroups if necessary

[Saied Kazemi]

Serge,

Thank you for sharing your thoughts on how cgroups configuration should be
implemented.  I have copied Garrison Bellack who will be working this.

Regarding restoring cgroups, I agree with you that CRIU should support the
cases and options you have mentioned.  I assume that Tycho will be sending
an update to his previous patch.

--Saied






On Thu, Jun 26, 2014 at 12:44 PM, Serge Hallyn <serge.hallyn at ubuntu.com>
wrote:

> Quoting Saied Kazemi (saied at google.com):
> > Pavel,
> >
> > Just a quick follow up:
> >
> > > 1. cgroups sub-hierarchy
> > > 2. configuration of cgroups
> > > 3. populating cgroups with tasks
> > > 4. creating cgroup mountpoints (if any)
> >
> > Pertaining to the list above, one of our interns is working on #2 and
> will
>
> Note that what Tycho is working on (1) should be coordinated with (2).
> The cgroups should be checkpointed as a hierarchical set of structs
> mirrorring the cgroup fs trees (and imo the cg_ctls should then point
> into these trees), so something like
>
> struct cgroup {
>         char *name;
>         struct list_head children;
>         int n_contollers;  // # of co-mounted controllers
>         char *controllers[];
>         struct mem_limits *mem_limits;
>         struct devcg_limits *devcg_limits;
>         ...
> };
>
> struct list_head init_cgroup_heads;
>
> struct cg_ctl {
>         struct list_head list;  // connect all (not-comounted) controllers
>         struct cgroup *cgroup;
> }
>
> > probably have a patch in a month.  Please let me know if someone is
> already
> > working on this to avoid duplication of effort.
> >
> > > With a CLI option we tell CRIU:
> > >
> > > 1. Expect the cgroup to already exist, just put the process back in it.
> >  If cgroup doesn't exist, fail.
> > > 2. Expect the cgroup not to exist, create it and put the process in it.
> >  If cgroup exists, fail.
> >
> > I was wondering if you had a chance to think about this.  As explained
> > before, there are legitimate cases where the cgroups do already exist
> prior
> > to criu restore, so their absence is a definite error.  Also, there are
> > legitimate cases where the cgroups do not already exist prior to criu
> > restore, so CRIU should create them.  CRIU on its own cannot determine
> > which scenario it's dealing with.  We can make the default action to
> always
> > create cgroups, but we still need a mechanism to tell it otherwise.
>
> And there are many legitimate cases where we care about the parent
> cgroup under which the restarted tasks should be grouped, but the
> actual cgroup name doesn't matter.  At the very least criu should have
> an option to rename the head cgroup, so that the caller can create a
> new cgroup with mkstemp, and pass that name on to criu, which can then
> populate all child cgroups under there.
>
> My preference is still for a template option, to say that if we
> checkpointed u1, then we will restarted some template beginning with
> u1, but just allowing the caller to specify a name would be fine.
>
> To be more precise, if the init task of the set being checkpointed
> was in cgroups /lxc/u1, and criu restore is called with "--cgroup-into x1",
> then criu would restore into /lxc/x1.
>
> -serge
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140626/64c80ee4/attachment-0001.html>