Line 1: |
Line 1: |
− | 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]] |
Line 20: |
Line 20: |
| 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. |
| | | |
− | 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.
| + | 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. |
| | | |
| == How to use this with CRIU == | | == How to use this with CRIU == |
Line 32: |
Line 32: |
| 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 |
Line 45: |
Line 45: |
| | | |
| ;<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 == |
Line 51: |
Line 51: |
| * [[Incremental dumps]] | | * [[Incremental dumps]] |
| * [[Memory dumping and restoring#Advanced C/R]] | | * [[Memory dumping and restoring#Advanced C/R]] |
| + | * [[Directories]] |
| | | |
| == External links == | | == External links == |