[CRIU] Combining pre-copy and post-copy

[Mike Rapoport]

On Fri, Jul 29, 2016 at 04:31:49PM +0200, Adrian Reber wrote:
> On Fri, Jul 29, 2016 at 03:18:56PM +0300, Pavel Emelyanov wrote:
> > On 07/28/2016 04:11 PM, Mike Rapoport wrote:
> > > On Wed, Jul 27, 2016 at 01:27:28PM +0200, Adrian Reber wrote:
> > >> Thanks for getting the remote uffd support into criu-dev.
> > >>
> > >> I am now looking at combining pre-copy and post-copy. Luckily there is
> > >> for each pagemap entry the status if the page is in a parent checkpoint
> > >> or not. Which makes it easier to decide if the page should be handled by
> > >> uffd or not.
> > >>
> > >> Unfortunately this information is not available in the restorer. The
> > >> restorer only gets a list of VMAs and if the page should handled by uffd
> > >> is decided by vma_entry_can_be_lazy()
> > >>
> > >>         return ((e->flags & MAP_ANONYMOUS) &&
> > >>                 (e->flags & MAP_PRIVATE) &&
> > >>                 !(vma_entry_is(e, VMA_AREA_VDSO)) &&
> > >>                 !(vma_entry_is(e, VMA_AREA_VSYSCALL)));
> > >>
> > >> Which has no information about parents. What would be the best way to
> > >> include the information if the page exists in a parent checkpoint and
> > >> therefore should not be handled by uffd?
> > > 
> > > I think that the best way is to make restore and uffd use the information
> > > in the pagemap to detect lazy and/or zero pages.
> 
> That was also my first idea. But at a second thought it seemed to coarse
> and did want to lose possible pages because of relying on the pagemap
> information only.
 
The pagemap should be pretty accurate, unless I've screwed it with the
latest changes.

The intention was to have the following pagemap states:
- zero pages are marked as zero, no matter if they are found in the parent
  snapshot
- pages found in the parent snapshot are marked with 'parent'
- pages that were skipped by the dump because they may be lazy are marked
  as 'lazy'
- at last the pages present in pages*img have no flags set

> > > For instance, the restore_priv_vma_content function should skip the entire
> > > lazy pagemap. And uffd initialization of relevant page sets should also
> > > rely on the pagemap flags rather than on vma_entry_can_be_lazy().
> > 
> > But why do we need the vma for this? When #PF happens we can find the pagemap
> > entry which has all we need.
> 
> The restorer only works with the VMA entries. It does not know anything
> about pagemap entries (as far as I can tell).

As far as I understand, the restorer reads pagemap one by one and then for
every page in the pagemap it searches for VMA the page belongs to.
IMHO, if the pagemap entry has 'zero' or 'lazy' flag set, it can be skipped
entirely...
 
> Currently I am doing the following: I added an additional flag to the
> VMA entry called lazy which I set if the page is lazy and if it is not
> in a parent checkpoint. To do this I split existing VMA entries, if
> necessary, to better match pagemap boundaries. This almost works I only
> have problems that the criu server on the source side thinks these pages
> are zeropages. They are marked as lazy in the pagemap, so that I have to
> figure out what is going on.
> 
> I will post the patches for this once it works.
> 
> 		Adrian
>