[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