Line 7: |
Line 7: |
| | | |
| * The <code>restore</code> action accepts yet another API switch: option <code>--lazy-pages</code>. In this mode, <code>restore</code> skips injection of lazy pages into the processes address space, but rather registers lazy memory areas with userfaultfd. | | * The <code>restore</code> action accepts yet another API switch: option <code>--lazy-pages</code>. In this mode, <code>restore</code> skips injection of lazy pages into the processes address space, but rather registers lazy memory areas with userfaultfd. |
− | * The lazy pages are completely handled by dedicated <code>lazy-pages</code> daemon. The daemon recieves userfault file descriptors from <code>restore</code> via UNIX socket. The userfault file descriptors allow reception of page-fault and other events and resolution of these events by the daemon. | + | * The lazy pages are completely handled by dedicated <code>lazy-pages</code> daemon. The daemon receives userfault file descriptors from <code>restore</code> via UNIX socket. The userfault file descriptors allow reception of page-fault and other events and resolution of these events by the daemon. |
| * For the migration case, the <code>dump</code> action also accepts API switch: option <code>--lazy-pages</code>. When this option is used, the <code>dump</code> keeps the memory pages and allows the <code>lazy-pages</code> daemon to request these pages via TCP connection. | | * For the migration case, the <code>dump</code> action also accepts API switch: option <code>--lazy-pages</code>. When this option is used, the <code>dump</code> keeps the memory pages and allows the <code>lazy-pages</code> daemon to request these pages via TCP connection. |
| | | |
Line 25: |
Line 25: |
| | | |
| * The [[page server]] is run on the remote side with <code>--lazy-pages</code> option. | | * The [[page server]] is run on the remote side with <code>--lazy-pages</code> option. |
− | * The lazy-pages daemon connects to the remote [[page server]] with <code>--page-server</code> option. The <code>--address</code> and <code>--port</code> options allow setting of IP addrees and port of the listening [[page server]]. | + | * The lazy-pages daemon connects to the remote [[page server]] with <code>--page-server</code> option. The <code>--address</code> and <code>--port</code> options allow setting of IP address and port of the listening [[page server]]. |
− | * Current protocol allows the lazy-pages daemon to request several continous pages. | + | * Current protocol allows the lazy-pages daemon to request several continuous pages. |
| | | |
| ==== Migration ==== | | ==== Migration ==== |
Line 37: |
Line 37: |
| * Currently only MAP_PRIVATE | MAP_ANONYMOUS is supported. Newer kernels (4.11+) allow userfaultfd for hugetlbfs and shared memory, yet to be implemented in CRIU. | | * Currently only MAP_PRIVATE | MAP_ANONYMOUS is supported. Newer kernels (4.11+) allow userfaultfd for hugetlbfs and shared memory, yet to be implemented in CRIU. |
| * Userfault is known not to map one page into two places. Thus -- COW-ed pages will get COW-ed. | | * Userfault is known not to map one page into two places. Thus -- COW-ed pages will get COW-ed. |
− | * The [[Lazy migration]] use-case might be racy because there is no means to synchronize between pending forks, remote pages transfers and page faults.
| |
| | | |
| == See also == | | == See also == |