[CRIU] [PATCH] opts: add --no-restore-cgroup option

[Saied Kazemi]

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.

--Saied



On Mon, Aug 4, 2014 at 11:17 AM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> On 08/04/2014 10:10 PM, Serge Hallyn wrote:
> > Quoting Pavel Emelyanov (xemul at parallels.com):
> >> On 08/04/2014 08:08 PM, Saied Kazemi wrote:
> >>> 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.
> >>>
> >>> 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).
> >>>
> >>> In short, CRIU usage will be easier with less options.
> >>
> >> I agree, but how about dump -- if we can ask criu not to dump cgroups,
> this would be
> >> less cpu cycles on dump, it will be faster :)
> >
> > Is that meaningful percentage of dump time?  It ought to be quite quick.
>
> I can't tell for sure, but I once measured how much time it takes to dump a
> small task. ~30% of time criu spent looking up and parsing various /proc
> files.
>
> Thus I'm a little bit concerned about scanning even virtual file systems
> in vain :)
>
> Thanks,
> Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140804/f685162b/attachment.html>