[CRIU] Reg unix stream checkpointing and other issues.

Pavel Emelyanov xemul at parallels.com
Fri Sep 12 09:07:50 PDT 2014


On 09/12/2014 07:19 PM, Sanidhya Kashyap wrote:
> Thanks for the info Pavel.
> 
> 
>>
>>>>
>>>> This is AIO mapping. We're working on supporting this, patches are
>>>> expected to appear by v1.4 :)
>>>>
>>>
>>> That's great!! When can I expect the 1.4 version? Or are those patches
>>> already upstreamed?
>>
>> Our release policy is like this: http://criu.org/Release_schedule
>> But note, that releases are time-driven, not feature-driven. So if
>> the patches are not ready till 1.4 they are delayed till next release.
>>
> 
> Well, is the AIO patch available on the mailing list? If yes, it would
> be great if you can point out the thread link which I can look at.

The beginnings appeared here: http://lists.openvz.org/pipermail/criu/2014-August/015853.html
No news from the guy since then :)

>>> By API do you mean kernel API or something else?
>>
>> I mean CRIU API. We have 3 of them (http://criu.org/API_compliance).
>> As far as multiple PIDs feature is concerned, we will probably need to:
>>
>> 1. make the --tree option accept the comma/colon-separated list
>> 2. fix the pstree (process tree) restore code to bear with multiple
>>    root tasks
>> 3. audit the code for checks for root process and think would they
>>    break or not (there are a couple of places about it)
>> 4. test it. I'd suggest modifying the zdtm suite so that it launches,
>>    dumps and restores more than one test at a time
>>
> 
> Then, I'll look at these in sometime as I am quite interested.
> 
> Another question that I have in my mind is about the restoring of the
> process. Well, with the help of memory changes tracking, we can
> decrease the freeze time of a process while checkpoitning, but what
> about the restore? I guess, that tracking part can't be used in the
> case of restoration.
> 
> What are the possible ways to improve the restore similar to the checkpointing?

We can do incremental restore, but it's quite tricky. The process
of migration would look like this then.

1. Get the process tree and their memory
2. Go on restore node, fork tasks and put the memory in places
3. Go back on source node, get the tree and changed memory
4. Go on restore node, fixup the tree by killing died tasks
   and forking the appeared ones, then update their memory
5. Repeat steps 3 and 4 some more times

The trickiest part is step #4. I have no nice algorithm for "fixup the tree"
step of it. Tuning up changed memory is more or less clear how to do.

Thanks,
Pavel



More information about the CRIU mailing list