Difference between revisions of "Memory images deduplication"
(add "memory dumps" to see also, api and under the hood to categories) |
(Add 'impementation notes', 'auto-dedup' description for criu restore) |
||
| Line 1: | Line 1: | ||
When performing [[incremental dumps]] or [[iterative migration]], a layered stack of memory images is created. In that stack, some data is duplicated (i.e. same memory page is present in multiple images). This article describes ways to deduplicate such data by punching holes in image files (using <code>fallocate()</code> syscall with <code>FALLOC_FL_PUNCH_HOLE</code> flag), effectively freeing used disk space. | When performing [[incremental dumps]] or [[iterative migration]], a layered stack of memory images is created. In that stack, some data is duplicated (i.e. same memory page is present in multiple images). This article describes ways to deduplicate such data by punching holes in image files (using <code>fallocate()</code> syscall with <code>FALLOC_FL_PUNCH_HOLE</code> flag), effectively freeing used disk space. | ||
| + | |||
| + | == Deduplication mode == | ||
Two ways to deduplicate memory images are available. | Two ways to deduplicate memory images are available. | ||
| − | == | + | === Offline === |
The <code>criu dedup</code> command opens the image directory and punches holes in the ''parent'' images where ''child'' images would replace them. | The <code>criu dedup</code> command opens the image directory and punches holes in the ''parent'' images where ''child'' images would replace them. | ||
| − | == On the fly deduplication == | + | === On the fly === |
| + | |||
| + | The <code>--auto-dedup</code> option can be used for <code>criu dump</code> and <code>criu page-server</code>. It causes every write to images with process' pages to punch holes in the respective parent images, which is extremely useful in [[disk-less migration]] scenario. | ||
| + | |||
| + | The <code>--auto-dedup</code> option can also be used for <code>criu restore</code>. This makes CRIU to punch holes in images as memory is being restored. This should be used if images are stored on tmpfs (i.e. in RAM, see [[disk-less migration]]), as this way RAM usage is not growing. | ||
| + | |||
| + | == Shared memory deduplication == | ||
| + | |||
| + | An experimental shared memory deduplication is currently (August 2016) available in CRIU development branch. | ||
| + | |||
| + | == Implementation notes == | ||
| − | + | Memory images are stored into two files: ''pagemap'' and ''pages'' (see [[memory dumps]] for details). Note that the deduplication process does not change ''pagemap'' in any way, it only punches holes in ''pages'' image files. | |
| − | + | Note that having a hole in an image file have totally different meaning that is in no way similar to the one of '''in_parent''' flag in ''pagemap'' entry (described in [[memory dumps]]). | |
== See also == | == See also == | ||
Revision as of 06:13, 31 August 2016
When performing incremental dumps or iterative migration, a layered stack of memory images is created. In that stack, some data is duplicated (i.e. same memory page is present in multiple images). This article describes ways to deduplicate such data by punching holes in image files (using fallocate() syscall with FALLOC_FL_PUNCH_HOLE flag), effectively freeing used disk space.
Deduplication mode
Two ways to deduplicate memory images are available.
Offline
The criu dedup command opens the image directory and punches holes in the parent images where child images would replace them.
On the fly
The --auto-dedup option can be used for criu dump and criu page-server. It causes every write to images with process' pages to punch holes in the respective parent images, which is extremely useful in disk-less migration scenario.
The --auto-dedup option can also be used for criu restore. This makes CRIU to punch holes in images as memory is being restored. This should be used if images are stored on tmpfs (i.e. in RAM, see disk-less migration), as this way RAM usage is not growing.
An experimental shared memory deduplication is currently (August 2016) available in CRIU development branch.
Implementation notes
Memory images are stored into two files: pagemap and pages (see memory dumps for details). Note that the deduplication process does not change pagemap in any way, it only punches holes in pages image files.
Note that having a hole in an image file have totally different meaning that is in no way similar to the one of in_parent flag in pagemap entry (described in memory dumps).