[CRIU] [PATCH 00/11] lazy-pages: handle multiple processes

[Mike Rapoport]

On Wed, Apr 13, 2016 at 10:05:29AM +0200, Adrian Reber wrote:
> On Mon, Apr 11, 2016 at 09:19:43AM +0300, Mike Rapoport wrote:
> > I took a liberty to implement handling of multiple processes in the
> > lazy-pages daemon before we've finished the design discussion about
> > communication protocol and page transfer related stuff.
> 
> I am not sure I completely understand the intentions behind this.
> 
> So it sounds like the uffd daemon running on the same side as the
> restore process, because right now we only have local lazy-restore,
> does not terminate after handling all page-requests from one restore.
> Which sounds good. But right now the part started with 'criu lazy-pages'
> still needs a checkpoint directory where it can read the checkpoint
> files. I haven't seen the point where the 'criu lazy-pages' part gets
> the new directory FD.

These patches do not change the way 'criu lazy-pages' treats the checkpoint
directory. The only real changes here is that instead of 'static pid' and
'static uffd' we have a context that creates a correspondence between pid
and uffd, and we are able to poll multiple uffd's.
 
> I don't have anything against this patch series, but this somehow is a
> decision in favor of a 'dumb' 'criu lazy-pages' which only forwards the
> requests from the network to the UFFD. As this is also my preferred
> solution I am happy to go this way, but from my point of view this
> somehow shortcuts our other discussion thread. If this is the way we
> want to continue then these patches are a good step in the right
> direction.
 
I don't see this series as a shortcut towards that or another decision in
our other discussion. We anyway need the ability to correlate uffd and pid,
and we anyway need the ability to handle multiple uffd's.
The other discussion is mostly about what happens at the time of a page
fault and this series is about how to get page faults from multiple
processes.

> 		Adrian
> 

--
Sincerely yours,
Mike.