[CRIU] [PATCH 1/2] cgroups: Add ability to reuse precreated controllers and cgroups
Cyrill Gorcunov
gorcunov at gmail.com
Fri May 22 06:21:06 PDT 2015
On Fri, May 22, 2015 at 04:05:30PM +0300, Pavel Emelyanov wrote:
> >>
> >> If directory already exists we just skip its options and go on.
> >
> > That's subcgroups.
>
> Huh? This code also makes top-level groups, no?
I suspect I'm messing with terminology. Let me point in example.
Assume we create container 100. So currently it will look like
/sys/fs/cgroup/<memory>/<100>
and criu does
mkdir(<memory>)
if (exist)
return
mount memory controller into <memory> directory
create subdir 100
if exist simply continue
With "strict" mode criu will do the same step by step.
In turn with "oppor" mode it try to create <memory>
if not exist, if exist -- simply continue. With "bind"
mode it requires <memory> to exist.
IOW, current --manage-cgroup <mode> covers how to
behave on cgroup roots. And I didn't change the behaviour
when criu handles cgroup 100 and subcgroup, but maybe I
should to?
> > Which I'm not sure how to propagate "strict" mode over
> > so I didn't change this code. That said the modes currently provided
> > are taking into account for toplevel cgroups only. Is it wrong?
> > (because it's early patches lets choose a strategy which fits best)
>
> Wait a second, let's imagine we're dumping an openvz container that lives
> in cgroup "100" and it has one sub-group called "foo". Then in the images
> there will be two cgroups -- "100" and "100/foo".
>
> Currently on restore criu will try to mkdir("100") and mkdir("100/foo").
> Whichever directory exists, criu will skip its properties restore and will
> do restore otherwise. IOW two modes exist -- "mkdir && props" or "nothing".
> We want to introduce the 3rd mode -- "props only", right?
Something like that, yes.
More information about the CRIU
mailing list