[CRIU] Lazy-restore design discussion - round 2

Pavel Emelyanov xemul at virtuozzo.com
Mon Apr 18 08:28:01 PDT 2016


On 04/18/2016 05:28 PM, Mike Rapoport wrote:
> On Mon, Apr 18, 2016 at 02:24:21PM +0300, Pavel Emelyanov wrote:
>> 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?
> 
> Well, I probably should have phrased it "page-xfer should be refactored to
> support split between pagemap and actual pages dump"...

Probably :) But in page-xfer we already have ->write_pagemap and ->write_pages.
Do you mean something more than this?

-- Pavel



More information about the CRIU mailing list