Changes

CRIU can detect what memory pages a task (or tasks) has changed since some moment of time. This page describes why this thing is required, how it works and how to use it.

CRIU can detect what memory pages a task (or tasks) has changed since some moment of time. This page describes why this is required, how it works and how to use it.

== Why do we need to track memory changed ==

== Why do we need to track memory changed ==

There are several scenarios when detecting what parts of memory has changed is required:

There are several scenarios where detecting what parts of memory has changed is required:

; [[Incremental dumps]]

; [[Incremental dumps]]

In order to find out which memory pages have changed, we [http://lwn.net/Articles/546966/ patched] the kernel. Tracking the memory changes consists of two steps:

In order to find out which memory pages have changed, we [http://lwn.net/Articles/546966/ patched] the kernel. Tracking the memory changes consists of two steps:

* Tell the kernel that we want it to keep track of memory changes by particular task by writing 4 into <code>/proc/$pid/clear_refs</code> file.

* ask the kernel to keep track of memory changes (by writing 4 into <code>/proc/$pid/clear_refs</code> file for each $pid we are interested in).

and after a while

and, after a while,

* Get what pages were modified by task by reading its <code>/proc/$pid/pagemap</code> file and looking at so called ''soft-dirty'' bit in the pagemap entries.

* get the list of modified pages of a process by reading its <code>/proc/$pid/pagemap</code> file and looking at so called ''soft-dirty'' bit in the pagemap entries.

 

During the first step, kernel will re-map all the tasks' mapping in read-only manner. If a task then tries to write into any of its pages, a page fault will occur, and the kernel will note which page is being written to. Reading the <code>pagemap</code> file reveals this information.

On the first step kernel will re-map all the tasks' mapping in read-only manner. If a task will try to write into one of its pages later, a page fault would occur and the kernel would note which page was written to. Reading the <code>pagemap</code> file reveals this information.

== How to use this with CRIU ==

== How to use this with CRIU ==

First of all, the

First of all, the

  # criu check

  # criu check --feature mem_dirty_track

command (without the <code>--ms</code> option) should sat, that everything is OK. The thing is that the soft-dirty tracker is not yet merged upstream, thus you should make sure, that you're using the properly patched kernel.

command should say the feature is supported. The memory changes tracking was initially merged into Linux kernel v3.11, and was further polished until v3.18 (see [[Upstream kernel commits]] for details).

There are several options how this functionality can be used.

There are several command line options to use the functionality:

;<code>--prev-images-dir</code> option

;<code>--prev-images-dir</code> option

:This option says where the images from previous <code>dump</code> or <code>pre-dump</code> (see below) action reside. If possible, CRIU will not dump memory pages that hasn't changed since that time.

:This option is used to provide the path where images from a previous <code>dump</code> or <code>pre-dump</code> (see below) action reside. If possible, CRIU will dump only the memory pages that have been modified since that time.

;<code>--track-mem</code> option

;<code>--track-mem</code> option

;<code>pre-dump</code> action

;<code>pre-dump</code> action

:This action dumps only part of information about processes and does this keeping tasks frozen for minimally possible time. The images generated by pre-dump cannot and should not be used for restore. After this action the proper <code>dump</code> should be performed with properly configured <code>--prev-images-dir</code> path.

:This action dumps only part of the information about processes and does that by keeping tasks frozen for the shortest possible time. The images generated by pre-dump cannot and should not be used for restore. After this action the proper <code>dump</code> should be performed with properly configured <code>--prev-images-dir</code> path.

== See also ==

== See also ==

* [[Incremental dumps]]

* [[Incremental dumps]]

* [[Memory dumping and restoring#Advanced C/R]]

* [[Memory dumping and restoring#Advanced C/R]]

== External links ==

== External links ==