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

[Tycho Andersen]

On Mon, Aug 04, 2014 at 12:30:02PM -0700, Saied Kazemi wrote:
> 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.

I guess that is an interesting question. I was thinking of it as "dump
everything you can by default", but perhaps an enable option is the
right way to go in light of things like --tcp-established.

Tycho

> --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
> >
> >