Memory changes tracking - Revision history

Xemul: /* See also */

2019-03-27T10:14:24Z

2019-03-08T22:32:14Z

How to use this with CRIU: fix link

2019-03-08T22:31:24Z

+link to kernel commits

2018-12-29T15:51:03Z

Spelling and grammar fixes

2018-05-13T11:01:26Z

How to use this with CRIU: rewording for clarity

2018-05-13T10:44:00Z

How to use this with CRIU: rewording for clarity

2017-03-01T17:41:56Z

How to use this with CRIU: fix kernel feature info

2016-09-16T17:45:07Z

2016-08-30T00:22:40Z

How we track memory changes: rewrite a bit

2016-08-30T00:19:14Z

How we track memory changes: kill double vertical space

@@ Line 52: / Line 52: @@
 * [[Memory dumping and restoring#Advanced C/R]]
 * [[Directories]]
 == External links ==

@@ Line 34: / Line 34: @@
   # criu check --feature mem_dirty_track
-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 https://criu.org/Upstream_kernel_commits for details).
+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 command line options to use the functionality:

@@ Line 34: / Line 34: @@
   # criu check --feature mem_dirty_track
-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.
+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 https://criu.org/Upstream_kernel_commits for details).
 There are several command line options to use the functionality:

@@ 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 ==
-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]]

@@ Line 39: / Line 39: @@
 ;<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

@@ Line 45: / Line 45: @@
 ;<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 ==

@@ 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:
-* 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 ==

← Older revision		Revision as of 00:19, 30 August 2016
Line 25:		Line 25:

	* 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 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.
−

	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.		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.