Difference between revisions of "Userfaultfd"
Jump to navigation
Jump to search
(Created) |
|||
| Line 1: | Line 1: | ||
Collected on this page is the design notes about supporting userfaultfd in CRIU | Collected on this page is the design notes about supporting userfaultfd in CRIU | ||
| + | |||
| + | |||
| + | == Concepts == | ||
| + | |||
| + | * Tasks after restore should have lazy VMAs being backed by userfaultfd, the fd itself should be sent before resume to CRIU daemon and closed | ||
| + | * Only MAP_PRIVATE | MAP_ANONYMOUS will be supported in the 1st version due to kernel constraints | ||
| + | * On source side the [[page server]] should be taught to use page-read to send pages out on the destination one | ||
| + | * Protocol should include out-of-order pages and background pages pushing (sending them before demand from the process) | ||
| + | * The now dump-only <code>--page-server</code> option should be used for restore action to tell that the memory will be sucked in through page server | ||
[[Category:Memory]] | [[Category:Memory]] | ||
Revision as of 15:56, 26 February 2015
Collected on this page is the design notes about supporting userfaultfd in CRIU
Concepts
- Tasks after restore should have lazy VMAs being backed by userfaultfd, the fd itself should be sent before resume to CRIU daemon and closed
- Only MAP_PRIVATE | MAP_ANONYMOUS will be supported in the 1st version due to kernel constraints
- On source side the page server should be taught to use page-read to send pages out on the destination one
- Protocol should include out-of-order pages and background pages pushing (sending them before demand from the process)
- The now dump-only
--page-serveroption should be used for restore action to tell that the memory will be sucked in through page server