<div dir="ltr">My preference would also have been to dump everything but in the light of what Pavel said about performance, CRIU needs to dump the minimum it needs. So, it's better to have it not dump cgroups by default and dump cgroups only if specifically told so by a command line option. I'd be fine with this.<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 12:35 PM, Tycho Andersen <span dir="ltr"><<a href="mailto:tycho.andersen@canonical.com" target="_blank">tycho.andersen@canonical.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="">On Mon, Aug 04, 2014 at 12:30:02PM -0700, Saied Kazemi wrote:<br>
> If performance has higher priority to usage, then I'd suggest that we add<br>
> an option to *enable* dumping cgroups (as opposed to the other way around)<br>
> because in most cases we will not have to dump and, therefore, there will<br>
> be one less option to specify on the command line.<br>
<br>
</div>I guess that is an interesting question. I was thinking of it as "dump<br>
everything you can by default", but perhaps an enable option is the<br>
right way to go in light of things like --tcp-established.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tycho<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> --Saied<br>
><br>
><br>
><br>
> On Mon, Aug 4, 2014 at 11:17 AM, Pavel Emelyanov <<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>><br>
> wrote:<br>
><br>
> > 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,<br>
> > LXC, migration agent, etc.) to create the cgroups before attempting to<br>
> > restore the process. In fact if restore is done on a different machine,<br>
> > the cgroups properties of the source machine may not even apply on the<br>
> > destination machine.<br>
> > >>><br>
> > >>> That said, I think we can/should do without --no-restore-cgroup option<br>
> > because the cgroups restore logic in CRIU should detect that everything is<br>
> > already setup and there is no need for it to do anything (effectively it<br>
> > 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,<br>
> > 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>
> > 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<br>
> > files.<br>
> ><br>
> > Thus I'm a little bit concerned about scanning even virtual file systems<br>
> > in vain :)<br>
> ><br>
> > Thanks,<br>
> > Pavel<br>
> ><br>
> ><br>
</div></div></blockquote></div><br></div>