Line 3: |
Line 3: |
| == Rationale == | | == Rationale == |
| | | |
− | For process tree migration, the biggest part of transfer data is the memory used by the processes. Therefore, optimizing this memory transfer would have the most benefit. | + | For process tree migration, the biggest part of transfer data is the memory used by the processes. Therefore, optimizing this memory transfer would be beneficial. |
| | | |
| + | [[Image:Memory_migration_without_page_server.png|thumb|500px|right|Memory migration without page server]] |
| Without the page server, migrating the user memory pages consists of: | | Without the page server, migrating the user memory pages consists of: |
− | * dumping the memory to files on disk; | + | * dumping (writing) the memory to files on disk; |
− | * copying the files over network to the destination system; | + | * reading the files and sending the data over the network to the destination host; |
| + | * receiving files on the destination host, writing to files on disk; |
| * restoring by reading the files into memory. | | * restoring by reading the files into memory. |
| | | |
− | Such a process incurs significant I/O overhead and slows down the migration. This overhead can be avoided by doing a direct memory to memory copy, avoiding any disk I/O.
| + | In other words, all the memory is written to the disk twice, and read from the disk also twice. It incurs significant I/O overhead and slows down the migration. The overhead is further multiplied when using <code>criu pre-dump</code> (such as for [[iterative migration]]), as in this case memory is dumped not once but a few times. |
| + | |
| + | A way to mitigate the disk I/O overhead is to use [[wikipedia:tmpfs|tmpfs]], a filesystem that use RAM as a storage (see [[Disk-less migration]] for details). This eliminates the disk I/O, but not the double read/write. To eliminate it, a page server mechanism was implemented. |
| + | <br clear="both"/> |
| | | |
| == Operation == | | == Operation == |
| | | |
− | FIXME
| + | [[Image:Memory_migration_with_page_server.png|thumb|500px|right|Memory migration with page server]] |
| + | When using page server, the memory is dumped not to disk, but directly to network, thus eliminating any disk reads/writes on the source. On the destination system, a page server runs, receiving the data from network and writing it to files on disk or tmpfs. |
| + | |
| + | === Pages deduplication === |
| + | |
| + | When iterative memory dumping feature (<code>criu pre-dump</code>) is used, memory is sent to page server a few times. The page server can automatically deduplicate pages, by punching holes in a parent images where child is replacing the page. This functionality is turned on by <code>--auto-dedup</code> option of <code>criu page-server</code> command. |
| + | <br clear="both"/> |
| + | |
| + | == Usage == |
| + | |
| + | See https://asciinema.org/a/15847. |
| + | |
| + | == See also == |
| + | |
| + | * [[P.Haul]] |
| + | * [[Live migration]] |
| + | * [[Lazy migration]] |
| + | |
| + | == External links == |
| + | |
| + | * Using page server: https://asciinema.org/a/15847 |
| | | |
| [[Category: HOWTO]] | | [[Category: HOWTO]] |
| [[Category: Development]] | | [[Category: Development]] |