[CRIU] [PATCH v5 3/5] Try to include userfaultfd with criu (part 1)

[Adrian Reber]

On Tue, Mar 15, 2016 at 12:03:07PM +0300, Pavel Emelyanov wrote:
> >> But do you really need to scan vmas in lazy pages daemon? Why not just
> >> respond with ANY vaddr request on the uffd. For this you'd only need
> >> the page-read engine.
> >>
> >> I mean the collect_uffd_pages code's list_for_each_entry(vma, &vmas->h, list)
> >> loop.
> > 
> > I need to know which pages do exist to be able to push unrequested pages
> > at some point into the restored process. To be able to stop the
> > lazy-pages daemon at some point because the process is happily running I
> > need to transfer pages, which have not yet been requested, into the
> > process. Some restored process might not touch certain pages maybe for a
> > long time (maybe hours or longer) and it would be good to have the
> > possibility to be able to end the UFFD daemon at some point. Therefore I
> > have to scan all existing pages if they are UFFD eligible and I have to
> > track if they have been requested. If they have not been requested after
> > some time I have to push the pages into the restored process to be able
> > to finish the UFFD daemon.
> 
> Hm... You're right, the termination point should be declared. To get this
> I have two suggestions, not sure which one would work better though.
> 
> The first is to teach lazy daemon to accept not just uffd + pid, but also
> the regions in which the client is willing to get memory.
> 
> The second suggestion is to just open the mm.img file and pull the vma entries
> into the lazy daemon. There's no such helper in criu code yet, so introducing
> one would be required.

I like this approach better and will try to implement it. Hoping that
this will work.

> And, not to block the progress, I suggest to do this: you fix the existing
> patches so that they just get rid of root_item dereference and teach the
> criu to lazy daemon protocol to pass pid. Then I merge them into criu-dev
> branch and wait for the patch that simplifies the vma-s management in
> either of the above ways? Then we proceed to multi-processes and other
> stuff. Does this sound OK for you?

Sure, great. Patches are coming.

		Adrian