<div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13px">Pavel,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Just a quick follow up:</span></div>
<span style="font-family:arial,sans-serif;font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>> 1. cgroups sub-hierarchy</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> 2. configuration of cgroups</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> 3. populating cgroups with tasks</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> 4. creating cgroup mountpoints (if any)</span><br><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Pertaining to the list above, one of our interns is working on #2 and will probably have a patch in a month. Please let me know if someone is already working on this to avoid duplication of effort.</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><div style="font-family:arial,sans-serif;font-size:13px">> With a CLI option we tell CRIU:</div><div style="font-family:arial,sans-serif;font-size:13px">
></div><div style="font-family:arial,sans-serif;font-size:13px">> 1. Expect the cgroup to already exist, just put the process back in it. If cgroup doesn't exist, fail.</div><div style="font-family:arial,sans-serif;font-size:13px">
> 2. Expect the cgroup not to exist, create it and put the process in it. If cgroup exists, fail.</div></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">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.</font></div>
<div><br></div><div><font face="arial, sans-serif">--Saied</font></div><div><font face="arial, sans-serif"><br></font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 25, 2014 at 10:11 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06/25/2014 08:36 PM, Serge Hallyn wrote:<br>
> Quoting Pavel Emelyanov (<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>):<br>
>> On 06/25/2014 07:55 PM, Serge Hallyn wrote:<br>
>>> Quoting Pavel Emelyanov (<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>):<br>
>>>> On 06/25/2014 07:06 PM, Serge Hallyn wrote:<br>
>>>><br>
>>>>> Another complication, btw, will be to do with relative cgroup paths. I can<br>
>>>>> probably abstract that behind the cgmanager abstraction when I add that,<br>
>>>>> but idea is - if I checkpointed u1 on the host, in /cpuset/lxc/u1, and now<br>
>>>>> restart it inside a nested container, then it should be restarted at<br>
>>>>> /cpuset/lxc/somecontainer/lxc/u1, perhaps even /cpuset/lxc/u1/lxc/u1.<br>
>>>><br>
>>>> How about do it two-step.<br>
>>>><br>
>>>> First, on dump all cgroup paths are dumped relative to root task groups.<br>
>>><br>
>>> What do you mean by 'root task groups'.<br>
>><br>
>> The paths to cgroups where the init task lives. In criu code this<br>
>> task is referenced by root_task variable, so we call it root always :)<br>
>><br>
>>> I would suggest: For each task, dump the cgroup path relative to the<br>
>>> init task being dumped.<br>
>><br>
>> +1, this is what I'm suggesting. But this would be tightly affected by<br>
>> the hierarchy dump. The thing is -- in task image (the core.proto one)<br>
>> we don't keep paths. We keep the cg_set identifier, which refers to the<br>
>> set of cgroups from cgroup image, which in turn contain paths.<br>
>><br>
>>> For the cgroup hierarchy, dump the path up to the dumping task's init's<br>
>>> cgroups.<br>
>><br>
>> Exactly.<br>
>><br>
>>> Then at restore, simply restore relative to the restoring path's init's<br>
>>> cgroups.<br>
>><br>
>> Em... Not clear what you mean here. Let's imagine criu lives in / cgroups<br>
><br>
> If I'm pid 2048 and call criu to restore a task, criu looks at my init's<br>
> cgroups (pid 1's cgroups) and restores relative to that.<br>
><br>
>> always. The container you dump lives in e.g. /cpuset/lxc/ct1/ one. On<br>
>> restore you want to move it into /cpuset/foo/lxc/ct1/ one.<br>
><br>
> No, by default it would go to /cpuset/lxc/ct1, since my init task is in<br>
> cgroup /.<br>
><br>
> If I'm now restarting it in a container which is in /cpuset/lxc/ct3,<br>
> then it gets moved to /cpuset/lxc/ct3/lxc/ct1.<br>
<br>
</div></div>Ah, I see. So we always recreate the same hierarchy structure relative<br>
to wherever criu sits. That's fine.<br>
<br>
Thanks,<br>
Pavel<br>
<br>
</blockquote></div><br></div>