[CRIU] Lazy-restore design discussion - round 3

[Pavel Emelyanov]

On 04/19/2016 12:39 PM, Adrian Reber wrote:
> The new summary:
> 
>  * 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
>    we will add the possibility to transfer the pages directly from the
>    checkpointed process.

Yes, and in the latter case the daemon will be started automatically by
criu dump.

Also, we have an ability to inherit the transports socket from criu caller
(see connect_to_page_server getting the fd without connecting).

>  * The transport protocol between the source system and the UFFD daemon
>    on the destination will be page-server based (something like Mike's patch)
> 
>  * The UFFD daemon will be able to handle multiple restore requests
>    (also Mike's patch "lazy-pages: handle multiple processes")
>    to restore a whole process tree.

Just to clarify -- each 'criu restore' requires its own uffd daemon. But each
uffd daemon can serve PF requests from many processes.

>  * For each restored process tree a new UFFD daemon is started.

Yup.

>  * The UFFD daemon is either started manually on the command-line
>    or automatically started by the restore process.

Yes.

>  * The UFFD daemon reads all required information (besides PID and UFFD)
>    from the checkpoint directory.

Yup.

>  * The UFFD daemon is the instance which decides which pages are pushed
>    when via UFFD into the restored process.

No, from my perspective uffd daemon (restore side) should be passive and
only forward PF-s to dump side and inject into tasks' address spaces
whatever pages arrive from restore side.

> Right now I am trying to find the minimal required points to get this
> implemented. Once this is done we can continue from there and start more
> discussions.
> 
> 		Adrian
> .
>