[CRIU] [PATCH 2/2] lazy-pages: add support to combine pre-copy and post-copy

[Mike Rapoport]

On Thu, Sep 08, 2016 at 03:25:07PM +0200, Adrian Reber wrote:
> On Thu, Sep 08, 2016 at 10:16:37AM +0300, Mike Rapoport wrote:
> > On Wed, Sep 07, 2016 at 06:24:32PM +0200, Adrian Reber wrote:
> > > From: Adrian Reber <areber at redhat.com>
> > > 
> > > To combine pre-copy (pre-dump) and post-copy (lazy-pages) mode the
> > > lazy-page mode must be made aware of pages which are only in the parent
> > > image and not in the current checkpoint image.
> > > 
> > > As the restorer only works on VmaEntry-s and knows nothing about PageMap
> > > entries the VmaEntry-s need to be adapted to match the PageMap entries.
> > > 
> > > This changes the lazy-page detection to not only rely on
> > > vma_entry_can_be_lazy() but to also check if the page is available in
> > > the parent. If the page is available in a parent checkpoint the page is
> > > not marked as lazy via a new VmaEntry field (optional bool lazy = 11).
> > > 
> > > If the VmaEntry does not have the same size as the PageMap entry the
> > > VmaEntry needs to be adapted to match the PageMap entry and then the new
> > > lazy flag can be set in the VmaEntry.
> > > 
> > > The restorer then additionally has to check if the VmaEntry has the lazy
> > > flag. If the lazy flag is not set, then the page is available in a
> > > parent checkpoint.
> > > 
> > > This code additionally adds a 'return 0;' to unmap_guard_pages() as the
> > > VmaEntry splitting can create multiple VmaEntry-s with MAP_GROWSDOWN and
> > > only the first entry needs the guard page to be unmapped.
> > 
> > I believe, that restorer and lazy-pages daemon should switch to using
> > pagemap for detection of memory areas that can be lazily restored. The
> > pagemap entry should contain enough information about the actual location
> > of the pages it describes. Then both restorer and lazy-pages daemon will
> > not need VMA data to determine the way for restoring the pages.
> 
> I am not sure that is really possible. At least it looks like it
> requires larger changes in the restorer. The restorer in criu/pie/ has
> no knowledge about the PageMap and all the information about the to be
> restored memory is in the VmaEntry-s. Information like PROT_READ,
> PROT_EXEC, MAP_PRIVATE, MAP_ANON, VMA_AREA_VSYSCALL, VMA_ANON_PRIVATE, ...
> Nothing of that is present in the PageMap. As I see it only the
> VmaEntry-s know about that information and if page is in the parent or
> not is in the PageMap. So I am not sure how the restorer can work on the
> PageMap.

Hmm, I've missed the pie restorer part...
The pagemap can have accurate information whether certain memory chunk may or
may not be restored using userfaultfd. This information is created from VMA
parameters at dump time and restorer can rely on that.
The question now, as I see it, what would be better: add a (probably sparse
) copy of pagemap to pie restorer arguments, or follow the route you
propose and make lazy/non-lazy distinction based on VmaEntry.

> 		Adrian
>

--
Sincerely yours,
Mike.