[CRIU] [PATCH 2/2] tests: add a test for --cgroup-root

[Pavel Emelyanov]

On 08/19/2014 07:29 PM, Tycho Andersen wrote:
> On Tue, Aug 19, 2014 at 06:00:52PM +0400, Pavel Emelyanov wrote:
>> On 08/19/2014 05:56 PM, Tycho Andersen wrote:
>>> On Tue, Aug 19, 2014 at 01:31:58PM +0400, Pavel Emelyanov wrote:
>>>> On 08/16/2014 02:02 AM, Tycho Andersen wrote:
>>>>> Signed-off-by: Tycho Andersen <tycho.andersen at canonical.com>
>>>>
>>>> This one fails with
>>>>
>>>>
>>>> Restore log: /root/criu/test/dump/static/cgroup02/7905/1/restore.log
>>>> --------------------------------- grep Error ---------------------------------
>>>> (00.012529)   7905: Error (cgroup.c:903): cg: Can't move into cpuset//newroot/tasks (-1/0): No space left on device
>>>
>>> Ah, hm. cpuset.7 says:
>>>
>>>       ENOSPC Attempted to write(2) the process ID (PID) of a process to a
>>>              cpuset tasks file  when  the cpuset had an empty cpuset.cpus or
>>>              empty cpuset.mems setting.
>>>
>>>       ENOSPC Attempted  to  write(2)  an empty cpuset.cpus or cpuset.mems
>>>              setting to a cpuset that has tasks attached.
>>>
>>>
>>> and there is this comment in the top of cgroup.c:
>>>
>>>         /*
>>>          * cpuset.cpus and cpuset.mems must be set before the process moves
>>>          * into its cgroup and hence can't be done here
>>>          */
>>>
>>> It looks like users still need to handle their cpuset.cpus and cpuset.mems
>>> settings manually? I can send a patch to fix it to handle it in the test, but
>>> it seems more like we should handle it in criu proper.
>>
>> Fix in CRIU would be better  :)
> 
> So this is a bit of an interesting case: the reason we restore cgroups
> and their properties after task restore is for speed, if the cg limits
> the number of cpus (or shares, etc.) that a process can use, restore
> is slower. Except this is exactly a case where we will do that.
> 
> I guess it would be ok to restore just these two properties before
> restoring the tasks?

I think this would work, yes. Another option would be to copy the masks
from parent cgroups and restore their "real" value at the very end. But
I'm OK with either implementation.

Thanks,
Pavel