[CRIU] Lazy-restore design discussion - round 2

[Mike Rapoport]

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"...
 
> >>>  * The UFFD daemon is the instance which decides which pages are pushed
> >>>    when via UFFD into the restored process.
> >>
> >> Not sure I understand this correctly. The UFFD daemon gets #PF-s from tasks
> >> and sends the requests to source node. The source node sends pages onto
> >> destination side (some go in out-of-order mode when #PF request from UFFD
> >> is received). The UFFD injects pages into processes right upon receiving.
> >>
> >>> Do we agree on these points? If yes, I would like to start to implement
> >>> it that way. If we get to the point where this works it still requires
> >>> lot of work on the tooling. For example how to split out the lazy-pages
> >>> from an existing dump, so that only the non-lazy-pages are actually
> >>> transferred to the destination system.
> >>>
> >>> 		Adrian
> >>> .
> >>>
> >>
> > .
> > 
>