<div dir="ltr">Serge,<div><br></div><div>Thank you for sharing your thoughts on how cgroups configuration should be implemented. I have copied Garrison Bellack who will be working this.</div><div><br></div><div>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.</div>
<div><br></div><div>--Saied</div><div><br></div><div><br></div><div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 26, 2014 at 12:44 PM, Serge Hallyn <span dir="ltr"><<a href="mailto:serge.hallyn@ubuntu.com" target="_blank">serge.hallyn@ubuntu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Quoting Saied Kazemi (<a href="mailto:saied@google.com">saied@google.com</a>):<br>
> Pavel,<br>
><br>
> Just a quick follow up:<br>
><br>
> > 1. cgroups sub-hierarchy<br>
> > 2. configuration of cgroups<br>
> > 3. populating cgroups with tasks<br>
> > 4. creating cgroup mountpoints (if any)<br>
><br>
> Pertaining to the list above, one of our interns is working on #2 and will<br>
<br>
</div>Note that what Tycho is working on (1) should be coordinated with (2).<br>
The cgroups should be checkpointed as a hierarchical set of structs<br>
mirrorring the cgroup fs trees (and imo the cg_ctls should then point<br>
into these trees), so something like<br>
<br>
struct cgroup {<br>
char *name;<br>
struct list_head children;<br>
int n_contollers; // # of co-mounted controllers<br>
char *controllers[];<br>
struct mem_limits *mem_limits;<br>
struct devcg_limits *devcg_limits;<br>
...<br>
};<br>
<br>
struct list_head init_cgroup_heads;<br>
<br>
struct cg_ctl {<br>
struct list_head list; // connect all (not-comounted) controllers<br>
struct cgroup *cgroup;<br>
<div class="">}<br>
<br>
> probably have a patch in a month. Please let me know if someone is already<br>
> working on this to avoid duplication of effort.<br>
><br>
> > With a CLI option we tell CRIU:<br>
> ><br>
> > 1. Expect the cgroup to already exist, just put the process back in it.<br>
> If cgroup doesn't exist, fail.<br>
> > 2. Expect the cgroup not to exist, create it and put the process in it.<br>
> If cgroup exists, fail.<br>
><br>
> I was wondering if you had a chance to think about this. As explained<br>
> before, there are legitimate cases where the cgroups do already exist prior<br>
> to criu restore, so their absence is a definite error. Also, there are<br>
> legitimate cases where the cgroups do not already exist prior to criu<br>
> restore, so CRIU should create them. CRIU on its own cannot determine<br>
> which scenario it's dealing with. We can make the default action to always<br>
> create cgroups, but we still need a mechanism to tell it otherwise.<br>
<br>
</div>And there are many legitimate cases where we care about the parent<br>
cgroup under which the restarted tasks should be grouped, but the<br>
actual cgroup name doesn't matter. At the very least criu should have<br>
an option to rename the head cgroup, so that the caller can create a<br>
new cgroup with mkstemp, and pass that name on to criu, which can then<br>
populate all child cgroups under there.<br>
<br>
My preference is still for a template option, to say that if we<br>
checkpointed u1, then we will restarted some template beginning with<br>
u1, but just allowing the caller to specify a name would be fine.<br>
<br>
To be more precise, if the init task of the set being checkpointed<br>
was in cgroups /lxc/u1, and criu restore is called with "--cgroup-into x1",<br>
then criu would restore into /lxc/x1.<br>
<span class="HOEnZb"><font color="#888888"><br>
-serge<br>
</font></span></blockquote></div><br></div>