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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
