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

Adrian Reber adrian at lisas.de
Tue Mar 29 03:39:53 PDT 2016


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.

		Adrian


More information about the CRIU mailing list