[CRIU] Remote lazy-restore design discussion

[Pavel Emelyanov]

On 04/11/2016 01:21 PM, Adrian Reber wrote:
> On Mon, Apr 11, 2016 at 01:15:52PM +0300, Pavel Emelyanov wrote:
> [...]
>>>> When available for read, it gets request for particular pagemap and pops one
>>>> up in the queue.
>>>
>>> How many pages are you planning to send upon request? The entire sequence
>>> that contains the faulted page, just the page that was requested, or, say,
>>> the page that was requested plus two pages before and two pages after?
>>
>> That's good question and it deserves separate long discussion :) I would start
>> with requesting a single page.
> 
> David Gilbert, who worked on the QEMU post-copy implementation, told us
> that that was one of tricks done for QEMU, that not only the page
> requested is been transmitted, but also the following pages assuming
> that the process probably will need those pages soon.

OK, but this suits well into what I've proposed. Restore side sends a
request for #PF page only, but as a result dump side can send as many
pages as it wants. Upon arrival those pages will be inserted into the
process' VMs.

BTW, this drives us into conclusion that the restore side is passive, i.e.
it only sends PF-s to dump side and injects whatever pages arrive. While
the dump side is active -- it should evaluate when and what pages to send.

-- Pavel