[CRIU] [PATCH] cg: don't try to copy special props to cpuset:/

[Pavel Emelyanov]

On 10/03/2014 07:07 PM, Tycho Andersen wrote:
> On Fri, Oct 03, 2014 at 07:02:03PM +0400, Pavel Emelyanov wrote:
>> On 10/03/2014 05:30 PM, Tycho Andersen wrote:
>>> On Fri, Oct 03, 2014 at 12:47:39PM +0400, Pavel Emelyanov wrote:
>>>> On 10/03/2014 03:40 AM, Tycho Andersen wrote:
>>>>> We can't write to cpuset's root cg (indeed, we didn't create it and it has
>>>>> stuff in it), so ignore this special case.
>>>>
>>>> Wait a second. I though we should avoid writing the "special props"
>>>> to all directories that we did *not* created on restore. Is this
>>>> assumption correct?
>>>
>>> Yes, that's what we should do (and you're right that this patch
>>> doesn't guarantee that). However, that does mean that users could set
>>> their cgroups up in a way that the restore can't succeed.
>>
>> But isn't it the user's problem? Let's make CRIU's behavior simple and
>> predictable -- if the directory exists, CRIU assumes that it's already
>> set up properly and just doesn't touch one. Does this make sense you?
> 
> Yes, agreed.

Great! Then I'm looking forward to the patch that would propagate the 
cpuset mask down the tree, but skipping the directories, that are 
already there.

>>> Another issue is that if the user migrates to a node with fewer CPUs,
>>> the restore will fail. e.g. if they have a cpuset.cpus == 0-3, and
>>> they migrate to a machine with only two cores (cpuset.cpus == 0-1), we
>>> will try to write 0-3 in and fail.
>>
>> I agree.
>>
>> BTW, won't we hit the similar issue with e.g. memory? If we migrate from
>> large-RAM box with big memory limit to small-RAM box and set this big mem
>> limit so that it effectively covers all the new box's RAM? I suppose these
>> two are the problems of different level and we shouldn't teach CRIU to
>> solve them in the fully automatic way.
> 
> Yes, I agree. We can leave it up to higher level tools that know about
> these things. What is a good interface to expose here? It seems like a
> cli for rewriting would be painful, maybe it is better to expose the
> .proto for cgroup and have the higher level tools just rewrite the
> images before restore. Another option would be to have something like
> --override-hardware-related-cgroups which just ignores the properties
> for these special cgroups.

Smth that worth thinking about :) Yet we have a problem with cgroup props
that were not restored by criu and (probably) those missing in the kernel but
present in the image.

Sigh. Need some really generic API using which CRIU can ask some external
tool/script/licrary to help with this. I'll try to come up with some proposal
by the time we meet on Plumbers :)

Thanks,
Pavel