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

[Tycho Andersen]

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?

Tycho