[CRIU] Lazy-restore design discussion - round 2

[Pavel Emelyanov]

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 :)

>  * On the source system there will be process listening on a network
>    socket. In the first implementation it will use a checkpoint
>    directory as the basis for the UFFD pages and in a later version
>    it will transfer the pages directly from the checkpointed process.

Yup. And also the ability to do restore from local images using uffd will
also be preserved (this is how the current code works).

>  * The transport protocol between the source system and the UFFD daemon
>    on the destination will be page-server based (something like Mike's patch)

Agreed.

>  * The UFFD daemon will be able to handle multiple restore requests
>    (also Mike's patch "lazy-pages: handle multiple processes")

Yes.

>  * 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.

>  * 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 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
> .
>