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

[Saied Kazemi]

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.

--Saied



On Mon, Aug 4, 2014 at 12:35 PM, Tycho Andersen <
tycho.andersen at canonical.com> wrote:

> 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
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140804/b6173e90/attachment.html>