Source system:<\/p>\n
- \n
- criu dump -D \/checkpoint\/destination -t PID<\/tt><\/li>\n
- rsync -a \/checkpoint\/destination destination.system:\/checkpoint\/destination<\/tt><\/li>\n<\/ul>\n
Destination system:<\/p>\n
- \n
- criu restore -D \/checkpoint\/destination<\/tt><\/li>\n<\/ul>\n
For large processes the migration duration can be rather long. For a process using 24GB this can lead to migration duration longer than 280 seconds. The limiting factor in most cases is the interconnect between the systems involved in the process migration.<\/p>\n
Optimization: Pre-Copy<\/h3>\n
One existing solution to decrease process downtime during migration is pre-copy. In one or multiple runs the memory of the process is copied from the source to the destination system. With every run only memory pages which have change since the last run have to be transferred. This can lead to situations where the process downtime during migration can be dramatically decreased.<\/p>\n
This depends on the type of application which is migrated and especially how often\/fast the memory content is changed. In extreme cases it was possible to decrease process downtime during migration for a 24GB process from 280 seconds to 8 seconds with the help of pre-copy.<\/p>\n
This approach is basically the same if migrating single processes (or process groups) or virtual machines.<\/p>\n
It Always Depends On…<\/h3>\n
Unfortunately pre-copy optimization can also lead to situations where the so called optimized case with pre-copy can require more time than the unoptimized case:<\/p>\n
![](\"https:\/\/lisas.de\/~adrian\/migration-time.png\")
<\/p>\nIn the example above a process has been migrated during three stages of its lifetime and there are situations (state: Calculation<\/em>) where pre-copy has enormous advantages (14 seconds with pre-copy and 51 seconds without pre-copy) but there are also situations (state: Initialization<\/em>) where the pre-copy optimization increases the process downtime during migration (40 seconds with pre-copy and 27 seconds without pre-copy). It depends on the memory change rate.<\/p>\n
Optimization: Post-Copy<\/h3>\n
Another approach to reduce the process downtime during migration is post-copy. The required memory pages are not dumped and transferred before restoring the process but on demand. Each time a missing memory page is accessed the migrated process is halted until the required memory pages has been transferred from the source system to the destination system:<\/p>\n
![](\"https:\/\/lisas.de\/~adrian\/memory-transfer-after-migration.png\")
<\/p>\nThanks to userfaultfd<\/em> this approach (or optimization) can be now integrated into CRIU<\/em>. With the help of userfaultfd<\/em> it is possible to mark memory pages to be handled by userfaultfd<\/em>. If such a memory page is accessed, the process is halted until the requested page is provided. The listener for the userfaultfd<\/em> requests is running in user-space and listening on a file descriptor. The same approach has already been implemented for QEMU<\/em>.<\/p>\n
Enough Theory<\/h3>\n
With all the background information on why and how the initial code to restore processes with userfaultfd<\/em> support has been merged into the CRIU<\/em> development branch: criu-dev<\/a>. This initial implementation of lazy-pages<\/a> support does not yet support lazy process migration between two hosts, but with the upstream merged patches it is at least possible to checkpoint a process and to restore the process using userfaultfd<\/em>. A lazy restore consists of two parts. The usual ‘criu restore<\/tt>‘ part and an additional, what we call uffd daemon<\/em>, ‘criu lazy-pages<\/tt>‘ part. To better demonstrate the advantages of a lazy restore there are patches to enhance crit<\/a> (CRiu Image Tool) to remove pages which can be restored with userfaultfd<\/em> from a checkpoint directory. Using a test case which allocates about 200MB of memory (and which writes one byte in each page over and over) requires after being dumped about 200MB. Using the mentioned crit<\/em> enhancement make-lazy<\/em> reduces the size of the checkpoint down to 116KB:<\/p>\n
$ crit make-lazy \/tmp\/checkpoint\/ \/tmp\/lazy-checkpoint\n$ du -hs \/tmp\/checkpoint\/ \/tmp\/lazy-checkpoint\n 201M \/tmp\/checkpoint\n 116K \/tmp\/lazy-checkpoint\n<\/pre>\n
With this the data which actually has to be transferred during process downtime is drastically reduced and the required memory pages are inserted in the restored process on demand using userfaultfd<\/em>. Restoring the checkpointed process using lazy-restore<\/em> would look something like this:<\/p>\n
First the uffd daemon:<\/em><\/p>\n
$ criu lazy-pages -D \/tmp\/checkpoint \n--address \/tmp\/userfault.socket<\/pre>\n
And then the actual restore:<\/p>\n
$ criu restore -D \/tmp\/lazy-checkpoint \n--lazy-pages --address \/tmp\/userfault.socket<\/pre>\n
The socket specified with --address<\/tt> is used to exchange information about the restored process required by the uffd daemon<\/em>. Once criu restore<\/tt> has done all its magic to restore the process except restoring the lazy memory pages, the process to be restored is actually started and runs until the first userfaultfd<\/em> handled memory page is accessed. At that point the process hangs and the uffd daemon<\/em> gets a message to provide the required memory pages. Once the uffd daemon<\/em> provides the requested memory page, the restored process continues to run until the next page is requested. As potentially not all memory pages are requested, as they might not get accessed for some time, the uffd daemon<\/em> starts to transfer unrequested memory pages into the restored process so that the uffd daemon<\/em> can shut down after a certain time.<\/p>\n","protected":false},"excerpt":{"rendered":"
Process Migration Using CRIU it is possible to checkpoint\/save\/dump the state of a process into a set of files which can then be used to restore\/restart the process at a later point in time. If the files from the checkpoint operation are transferred from one system to another and then used to restore the process, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,1],"tags":[],"class_list":["post-12","post","type-post","status-publish","format-standard","hentry","category-luges","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/posts\/12","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/comments?post=12"}],"version-history":[{"count":1,"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/posts\/12\/revisions"}],"predecessor-version":[{"id":22,"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/posts\/12\/revisions\/22"}],"wp:attachment":[{"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/media?parent=12"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/categories?post=12"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lisas.de\/luges\/index.php\/wp-json\/wp\/v2\/tags?post=12"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- rsync -a \/checkpoint\/destination destination.system:\/checkpoint\/destination<\/tt><\/li>\n<\/ul>\n