[CRIU] Lazy-restore design discussion - round 2

[Pavel Emelyanov]

On 04/18/2016 01:10 PM, Mike Rapoport wrote:
> On Mon, Apr 18, 2016 at 12:31:14PM +0300, Pavel Emelyanov wrote:
>> On 04/18/2016 10:46 AM, Adrian Reber wrote:
>>> It seems we have reached some kind of agreement and therefore
>>> I am trying to summarize, from my point of view, our current discussion
>>> results.
>>
>> Thanks for keeping track of this :)
> 
> Adrian, you've beat me on this :)
>  
>>>  * The UFFD daemon does not need a checkpoint directory to run, all
>>>    required information will be transferred over the network.
>>>    e.g. PID and pages
>>
>> I would still read process tree from images dir.
> 
> +1
>  
>>>  * The page-server protocol needs to be extended to transfer the
>>>    lazy-restore pages list from the source system to the UFFD daemon.
>>
>> You mean the pagemap-s? But we have the images dir on the destination node,
>> uffd can read this information from there as well.
> 
> The means that dump side should be teached to split pagemap creation and
> actual page dump, right?

Right, but it's already such. Is it?

>>>  * The UFFD daemon is the instance which decides which pages are pushed
>>>    when via UFFD into the restored process.
>>
>> Not sure I understand this correctly. The UFFD daemon gets #PF-s from tasks
>> and sends the requests to source node. The source node sends pages onto
>> destination side (some go in out-of-order mode when #PF request from UFFD
>> is received). The UFFD injects pages into processes right upon receiving.
>>
>>> Do we agree on these points? If yes, I would like to start to implement
>>> it that way. If we get to the point where this works it still requires
>>> lot of work on the tooling. For example how to split out the lazy-pages
>>> from an existing dump, so that only the non-lazy-pages are actually
>>> transferred to the destination system.
>>>
>>> 		Adrian
>>> .
>>>
>>
> .
>