[CRIU] [PATCH v2 5/5] UFFD: Support lazy-pages restore between two hosts

[Mike Rapoport]

On Tue, Mar 29, 2016 at 12:39:53PM +0200, Adrian Reber wrote:
> On Tue, Mar 29, 2016 at 12:42:27PM +0300, Pavel Emelyanov wrote:
> > On 03/29/2016 08:58 AM, Mike Rapoport wrote:
> > >> And this patch definitely requires tuning. First, as Mike notices, we already
> > >> have the code that makes dump send pages over the network -- the dump
> > >> --page-server makes this work, so for the server side I'd just extend the
> > >> dump action with the --lazy-pages option that would feed _more_ data into
> > >> page_sever_xfer after dump.
> > > 
> > > For actual post-copy, the dump action needs to remain active until all the
> > > pages are transfered to the destination. Moreover, dump action should be
> > > able to respond to requests rather than feed more data to the page_server
> > > running on the destination node. I think page_server should gain some
> > > symmetry and ability to run on the source node.
> > 
> > This fits well with the page_xfer driver :)
> 
> Thanks for the feedback. I haven't looked at the page server yet and
> cannot comment how well it is suited for lazy restore. I will have a
> look if it can be integrated.
> 
> What I liked about my approach was, that I was actually just forwarding
> the existing UFFD structures without the need to use different
> structures during the transfer and the actual UFFD actions. With this it
> was easy to use the same code for socket and UFFD read()/write(), which
> (as Mike mentioned) makes the code not as readable as possible but at
> the same time reduces code duplication.
 

> Let me have a look if and how the page server code fits the lazy restore
> case.

I've already started to look into it, seems that quite an update is
required there because currently CRIU page-server works the other way
around :)

> 		Adrian

--
Sincerely yours,
Mike.