[CRIU] Reg unix stream checkpointing and other issues.

[Pavel Emelyanov]

On 10/24/2014 09:37 PM, Sanidhya Kashyap wrote:
> On 10/24/2014 12:14 PM, Pavel Emelyanov wrote:
> 
> 
>>> - Is there a possibility of having a memory that is not present for
>>> the task? If yes, then how will that be handled?
>>
>> Right now no, but there's a work done by Andrea Arcangeli on the
>> userfaultd and memcopy system calls. I plan to write him an e-mail
>> about extending this API to fit our needs.
>>
> 
> I am thinking about this 'lazy migration' approach only. 

OK, in this case we should work on the full tree only.

>>> - There is a possibility that a forked task might call not yet started
>>> task. What will happen in this case?
>>
>> The pre-restored tree is not running, it's frozen.
>>
> 
> I don't think the incremental restore will have any performance benefits, whereas
> the lazy one will definitely have. I have done this for VMs. 

Lazy will, but it has another drawback -- once the source node is not
accessible while the destination still needs pages from it, all the
soon-to-be-restored tasks will die.

Pre-restore should have performance benefits as we will avoid big portion
of two stages -- fork() and memory restore -- which currently take quite
a lot of time.

>>> Besides this, I was thinking of another approach using userfaultfd.
>>> That is fork all the tasks but
>>> don't dump the memory and start the process. Later, when a page is
>>> accessed, it will result in
>>> page-fault handler invocation which should be handled by criu handling
>>> that page. What do you think of this approach?
>>
>> This is what we call "lazy migration" and yes, this is in our plans
>> too :) But the existing userfaultfd + memcopy API is not enough. The
>> latter syscall should operation on arbitrary task VM, not only on the
>> current one.
>>
> 
> It would be great if you can give me some details about the memcopy API 
> as I would like to work and develop a prototype for the whole lazy migration
> process.
> 
> Another question is that can I do it currently without extending the memcopy API?

I heavily doubt it. We cannot "make" restored process pull memory for itself.
We should have a userfault-daemon that will suck pages from dst node and
inject them into the remote processes.

> I would also like to discuss the model / approach for the lazy migration. If you 
> have something in mind, it would definitely help me a lot. Are you available on
> irc, where I can discuss the issues?

Sure. What is your timezone? Mine is MSK. I think we can meet some day next week.

Thanks,
Pavel