[CRIU] [PATCH 1/2] cgroups: Add ability to reuse precreated controllers and cgroups

[Pavel Emelyanov]

On 05/22/2015 04:21 PM, Cyrill Gorcunov wrote:
> 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. 

But "memory" is created on freshly mounted tmpfs, how can
it exist there?!

> With "bind" mode it requires <memory> to exist.

O_O

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

Yes. You should change the behavior on dir "100" only -- it
can exist, but criu have to restore props on it.

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