<div dir="ltr">If performance has higher priority to usage, then I'd suggest that we add an option to *enable* dumping cgroups (as opposed to the other way around) because in most cases we will not have to dump and, therefore, there will be one less option to specify on the command line.<div>
<br></div><div>--Saied</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 4, 2014 at 11:17 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 08/04/2014 10:10 PM, Serge Hallyn wrote:<br>
> Quoting Pavel Emelyanov (<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>):<br>
>> On 08/04/2014 08:08 PM, Saied Kazemi wrote:<br>
>>> Yes, in practice it would be the responsibility of an "agent" (Docker, LXC, migration agent, etc.) to create the cgroups before attempting to restore the process. In fact if restore is done on a different machine, the cgroups properties of the source machine may not even apply on the destination machine.<br>
>>><br>
>>> That said, I think we can/should do without --no-restore-cgroup option because the cgroups restore logic in CRIU should detect that everything is already setup and there is no need for it to do anything (effectively it becomes a noop).<br>
>>><br>
>>> In short, CRIU usage will be easier with less options.<br>
>><br>
>> I agree, but how about dump -- if we can ask criu not to dump cgroups, this would be<br>
>> less cpu cycles on dump, it will be faster :)<br>
><br>
> Is that meaningful percentage of dump time? It ought to be quite quick.<br>
<br>
</div></div>I can't tell for sure, but I once measured how much time it takes to dump a<br>
small task. ~30% of time criu spent looking up and parsing various /proc files.<br>
<br>
Thus I'm a little bit concerned about scanning even virtual file systems in vain :)<br>
<br>
Thanks,<br>
Pavel<br>
<br>
</blockquote></div><br></div>