[CRIU] Lazy-restore design discussion - round 2

[Adrian Reber]

On Mon, Apr 18, 2016 at 06:28:01PM +0300, Pavel Emelyanov wrote:
> On 04/18/2016 05:28 PM, Mike Rapoport wrote:
> > On Mon, Apr 18, 2016 at 02:24:21PM +0300, Pavel Emelyanov wrote:
> >> On 04/18/2016 01:10 PM, Mike Rapoport wrote:
> >>> On Mon, Apr 18, 2016 at 12:31:14PM +0300, Pavel Emelyanov wrote:
> >>>> 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 :)
> >>>
> >>> Adrian, you've beat me on this :)
> >>>  
> >>>>>  * 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.
> >>>
> >>> +1
> >>>  
> >>>>>  * 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 means that dump side should be teached to split pagemap creation and
> >>> actual page dump, right?
> >>
> >> Right, but it's already such. Is it?
> > 
> > Well, I probably should have phrased it "page-xfer should be refactored to
> > support split between pagemap and actual pages dump"...
> 
> Probably :) But in page-xfer we already have ->write_pagemap and ->write_pages.
> Do you mean something more than this?

My original point "The page-server protocol needs to be extended ..."
seems irrelevant now, as the uffd daemon will have access to the image
directory. We probably need to differentiate between write_pages() for
lazy-pages and write_pages() for non-lazy-pages, right?

		Adrian