Commit | Line | Data |
---|---|---|
0f8975ec PE |
1 | SOFT-DIRTY PTEs |
2 | ||
3 | The soft-dirty is a bit on a PTE which helps to track which pages a task | |
4 | writes to. In order to do this tracking one should | |
5 | ||
6 | 1. Clear soft-dirty bits from the task's PTEs. | |
7 | ||
8 | This is done by writing "4" into the /proc/PID/clear_refs file of the | |
9 | task in question. | |
10 | ||
11 | 2. Wait some time. | |
12 | ||
13 | 3. Read soft-dirty bits from the PTEs. | |
14 | ||
15 | This is done by reading from the /proc/PID/pagemap. The bit 55 of the | |
16 | 64-bit qword is the soft-dirty one. If set, the respective PTE was | |
17 | written to since step 1. | |
18 | ||
19 | ||
20 | Internally, to do this tracking, the writable bit is cleared from PTEs | |
21 | when the soft-dirty bit is cleared. So, after this, when the task tries to | |
22 | modify a page at some virtual address the #PF occurs and the kernel sets | |
23 | the soft-dirty bit on the respective PTE. | |
24 | ||
25 | Note, that although all the task's address space is marked as r/o after the | |
26 | soft-dirty bits clear, the #PF-s that occur after that are processed fast. | |
27 | This is so, since the pages are still mapped to physical memory, and thus all | |
28 | the kernel does is finds this fact out and puts both writable and soft-dirty | |
29 | bits on the PTE. | |
30 | ||
d9104d1c CG |
31 | While in most cases tracking memory changes by #PF-s is more than enough |
32 | there is still a scenario when we can lose soft dirty bits -- a task | |
33 | unmaps a previously mapped memory region and then maps a new one at exactly | |
34 | the same place. When unmap is called, the kernel internally clears PTE values | |
35 | including soft dirty bits. To notify user space application about such | |
36 | memory region renewal the kernel always marks new memory regions (and | |
37 | expanded regions) as soft dirty. | |
0f8975ec PE |
38 | |
39 | This feature is actively used by the checkpoint-restore project. You | |
40 | can find more details about it on http://criu.org | |
41 | ||
42 | ||
43 | -- Pavel Emelyanov, Apr 9, 2013 |