Re: [LSF/MM ATTEND] userfaultfd

[Pavel Emelyanov <xemul@virtuozzo.com>]

On 01/26/2017 04:08 PM, Mike Rapoport wrote:
> Hello,
> 
> I'm working on integration of userfaultfd into CRIU. Currently we can
> perform lazy restore and post-copy migration with the help of
> userfaultfd, but there are some limitations because of incomplete
> in-kernel support for non-cooperative mode of userfaultfd.
> 
> I'd like to particpate in userfaultfd-WP discussion suggested by
> Andrea Acangeli [1].

I'd like to support Mike's "self-nomination".

-- Pavel

> Besides, I would like to broaden userfaultfd discussion so it will
> also cover the following topics:
> 
> * Non-cooperative userfaultfd APIs for checkpoint/restore
> 
> Checkpoint/restore of an application that uses userfaultfd will
> require additions to the userfaultfd API. The new APIs are needed to
> allow saving parts of in-kernel state of userfaultfd during checkpoint
> and then recreating this state during restore.
> 
> * Userfaultfd and COW-sharing.
> 
> If we have two tasks that fork()-ed from each other and we try to
> lazily restore a page that is still COW-ed between them, the uffd API
> doesn't give us anything to do it. So we effectively break COW on lazy
> restore.
> 
> * Userfaultfd "nesting" [2]
> 
> CRIU uses soft-dirty to track memory changes. We would like to switch
> to userfaultfd-WP once it gets merged. If the process for which we are
> tracking memory changes uses userfaultfd, we would need some notion of
> uffd "nesting", so that the same memory region could be monitored by
> different userfault file descriptors. Even more interesting case is
> tracking memory changes of two different processes: one process that
> has memory regions monitored by uffd and another one that owns the
> non-cooperative userfault file descriptor to monitor the first
> process.
> The userfaultfd "nesting" is also required for lazy restore scenario so
> that CRIU will be able to use userfaultfd for memory ranges that the
> restored application is already managing with userfaultfd.
> 
> [1] http://www.spinics.net/lists/linux-mm/msg119866.html
> [2] https://www.spinics.net/lists/linux-mm/msg112500.html
> 
> .
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>