<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 10:05 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 06/24/2014 09:01 PM, Saied Kazemi wrote:<br>
<div class="">><br>
><br>
><br>
> On Tue, Jun 24, 2014 at 9:26 AM, Pavel Emelyanov <<a href="mailto:xemul@parallels.com">xemul@parallels.com</a> <mailto:<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>>> wrote:<br>
><br>
> On 06/24/2014 06:12 PM, Serge Hallyn wrote:<br>
><br>
> >> Yes. Emply cgroups cannot be discovered through /proc/pid/cgroup file,<br>
> >> we should walk the alive cgroup mount. But the problem is -- we cannot<br>
> >> just take the system /sys/fs/cgroup/ directories, since there will be<br>
> >> cgroups from other containers as well. We should find the root subdir<br>
> >> of the container we dump and walk _this_ subtree.<br>
> ><br>
> > I volunteer to work on a proper cgroup c/r implementation, once Tycho<br>
> > gets the very basics done.<br>
><br>
> Serge, Tycho, I think I need to clarify one more thing.<br>
><br>
> I believe, that once we do full cgroups hierarchy restore all the<br>
> mkdirs would go away from the move_in_cgroup() routine. Instead,<br>
> we will have some code, that would construct all the cgroup subtree<br>
> before criu will start forking tasks. And once we have it, the<br>
> move_in_cgroup() would (should) never fail. Thus this patch would<br>
> be effectively reversed.<br>
><br>
> Thanks,<br>
> Pavel<br>
><br>
><br>
> I agree. Creation of the cgroup and its subtree should be done in one place as opposed<br>
> to being split apart (i.e., between prepare_cgroup_sfd() and move_in_cgroup() as is done<br>
> currently).<br>
><br>
> Regarding the 4 items to do for cgroups in your earlier email, I believe that we should<br>
> have CLI options to tell CRIU what cgroups it needs to restore (almost like the way we<br>
> tell it about external bind mounts).<br>
<br>
</div>I was thinking that if we take the root task, check cgroups it lives in and<br>
dump the whole subtree starting from it, this would work properly and would<br>
not require and CLI hints.<br>
<br>
Do you mean, that we need to tell criu where in cgroup hierarchy to start<br>
recreating the subtree it dumped?<br>
<div class=""><br>
> This way we can handle the empty cgroups as well as dumping and restoring on the same<br>
> machine versus on a different machine (i.e., migration). For migration, CRIU definitely<br>
> needs to be told how to handle cgroups name collision.<br>
<br>
</div>But if we ask criu to restore tasks in a fresh new sub-cgroup, why would this<br>
collision happen?<br>
<div class=""><br>
> This is not something that it can handle at dump time.<br>
><br>
> --Saied<br></div></blockquote><div><br></div><div>I am not sure if I understand what is meant by "fresh new sub-cgroup". Since the process has to be restored in the same cgroup, I assume you mean a new mountpoint. But if the cgroup already exists, giving it a private new mountpoint doesn't mean that it will set up a new hierarchy. Consider the following example:</div>
<div><br></div><div><div># cat /sys/fs/cgroup/hugetlb/notify_on_release </div></div><div># mkdir /mnt/foo</div><div># mount -t cgroup -o hugetlb cgroup /mnt/foo<br></div><div><div># cat /mnt/foo/notify_on_release <br></div>
<div>0</div><div># echo 1 > /sys/fs/cgroup/hugetlb/notify_on_release<br></div><div># cat /mnt/foo/notify_on_release <br></div><div>1</div><div># echo 0 > /mnt/foo/notify_on_release </div><div># cat /sys/fs/cgroup/hugetlb/notify_on_release </div>
<div>0</div></div><div>#</div><div><br></div><div>So I think we need a mechanism to tell CRIU whether it should expect the cgroup already existing (e.g., restore on the same machine) or not (e.g., restore after reboot or on a different machine).</div>
<div><br></div><div>I am not a cgroups expert, but I hope it's more clear now.</div><div><br></div><div>--Saied</div><div><br></div></div></div></div>