[CRIU] [PATCH] Skip restoring certain cgroup root directories when using full mode

Hui Kang hkang.sunysb at gmail.com
Sun Aug 16 22:07:29 PDT 2015


On Sun, Aug 16, 2015 at 9:20 PM, Pavel Emelyanov <xemul at parallels.com> wrote:
> On 08/13/2015 07:41 PM, Hui Kang wrote:
>> Skip these top cgroup directories: cpu, cpuset, cpuacct, memory
>>
>> Signed-off-by: Hui Kang <hkang.sunysb at gmail.com>
>> ---
>>  cgroup.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/cgroup.c b/cgroup.c
>> index a4e0146..94749b1 100644
>> --- a/cgroup.c
>> +++ b/cgroup.c
>> @@ -992,6 +992,10 @@ static int prepare_cgroup_dir_properties(char *path, int off, CgroupDirEntry **e
>>               CgroupDirEntry *e = ents[i];
>>               size_t off2 = off;
>>
>> +             if (strcmp(e->dir_name, "") == 0 &&
>> +                 ((strstr(path, "cpu")) || (strstr(path, "memory"))))
>> +                     continue;
>> +
>
> With this "continue" won't we skip all the properties restore? The e-s we
> have here represent all the tree, starting from root and descending. If you
> skip the root one, then the whole subtree is skipped too.

No. Although the e-s represent the tree, the for loops will iterate
all the directories. With "full" mode, the top "cpu" and "mem"
directories should be skipped. The first condition
(strcmp(e->dir_name, "") guarantees that non-root directory will be
restored. For a dumped process with cgroup tree "cpuset/foo/foo1". The
restore process with "full" mode is like

(00.046731) cg: Restored cgroup property value 1 to cpuset/foo/foo1/cpuset.cpus

(00.046803) cg: Restored cgroup property value 0 to cpuset/foo/foo1/cpuset.mems

... (after all foo1 properties are restore, the it moves to the top level)

(00.047287) cg: ---> Skip Empty name for top path cpu , top dir

As you can see, the patch will only skip those root directories.

One side observations is that the property values of the intermediate
level (e.g., cpuset/foo) is not dumpped. I confirmed this by running
crit decode -i cgroup.img --pretty. So when restoring, I have to
manually create cpuset/foo and populate the value. Is this a bug of
CRIU?

>
> Also, how about the restore_special_cpuset_props?

I do not think this will affect restore_special_cpuset_props, because
restore_special_cpuset_props is called prior to
prepare_cgroup_dir_properties. In my debug trace version
(/cgroup/foo), it shows that

(00.001387) cg: Created cgroup dir cpuset/foo
(00.001615) cg: Restored cgroup property value 1 to cpuset/foo/cpuset.cpus
...

(00.001803) cg: Restored cgroup property value 0 to cpuset/foo/cpuset.mems
...

Restored cgroup property value 1 to cpuset/foo/cpuset.cpus
(00.056506) cg: ---> Skip Empty name for top path cpu ,

As you can see, after the cpuset is created by the full mode, the
restore process will still success. However, without the patch, it
fails in writing to root cpuset.cpus after create
cpuset/foo/cpuset.cpus

Error (cgroup.c:978): cg: Failed closing cpu//cpu.shares: Invalid argument

Thanks.

- Hui


>
>>               off2 += sprintf(path + off, "/%s", e->dir_name);
>>               if (e->n_properties > 0) {
>>                       for (j = 0; j < e->n_properties; ++j) {
>>
>


More information about the CRIU mailing list