[CRIU] Lazy-restore design discussion - round 3

[Mike Rapoport]

On Tue, Apr 19, 2016 at 01:24:09PM +0300, Pavel Emelyanov wrote:
> 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.
 
Why additional process is needed on the dump side? Why the criu dump itself
cannot go into "daemon mode" after collecting pagemap's and inserting the
memory pages into page-pipe?

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

This one is tough :)
I'm more biased towards making the receive side the smart one and the dump
side the dumb one.
I'd suggest that we start with teaching uffd to get pages over the network
instead of checkpoint directory on the destination, and after that works
we'll see which side should be the smart one. 
 
> > 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
> > .
> > 
>