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

[Pavel Emelyanov]

On 05/22/2015 03:03 PM, Cyrill Gorcunov wrote:
> On Fri, May 22, 2015 at 02:53:22PM +0300, Pavel Emelyanov wrote:
>> On 05/21/2015 10:33 PM, Cyrill Gorcunov wrote:
>>> When been playing wich checkpoint/restore of container I found
>>> that we can't reuse existing controller if they were pre-created.
>>> For example currently in PCS7 we're bindmount cgroups which belong
>>> to a container in a form of
>>>
>>>  /sys/fs/cgroup/<controller>/<container> ==> /sys/fs/cgroup/<controller>
>>>
>>> so that CRIU dumps such configuration fine but on restore
>>> it recreates controllers from the scratch which we would
>>> like to bindmount them and ask CRIU to restore subcgroups
>>> and their parameters.
>>>
>>> So I extended --manage-cgroups option to take <mode> arguments
>>> which might be
>>>
>>>  - strict: default mode -- no change in current behaviour,
>>>    we restore everything from the scratch failing with error
>>>    if some toplevel controller or cgroup already exist
>>
>> What do you mean by "default"? The mode when --mange-cgroups is
>> specified, but "mode" (argument) is not?
> 
> Yes. To keep backward compatibility.

The current behavior is _not_ to fail if some cgroup exists, but to
take it as is w/o modifying its parameters and populate with tasks.

>>
>>>  - opport: opportunistic mode -- if controller or toplevel
>>>    cgroup doesn't exist we create it, otherwise simply continue
>>>    execution. iow here we try to continue as long as we can.
>>>
>>>  - bind: bindmount mode -- implies that controller and toplevel
>>>    cgroup must already exist.
>>>
>>> The last mode allows me to premount cgroups for container externally
>>> and restore its limits from CRIU.
>>
>> I see that modes can be OR-ed. What do the combinations mean?
> 
> At the momen it doesn't do anything useful, because there are
> only plain tests when we're handling cgroups (ie most relaxed
> mode is tested first). But I think we might extend the semantics
> in future that's where OR came from.

OK, but maybe we should override modes with newer ones instead of
silently "not doing anything useful"?

-- Pavel