mm: soft-dirty bits for user memory changes tracking
The soft-dirty is a bit on a PTE which helps to track which pages a task
writes to. In order to do this tracking one should
1. Clear soft-dirty bits from PTEs ("echo 4 > /proc/PID/clear_refs)
2. Wait some time.
3. Read soft-dirty bits (55'th in /proc/PID/pagemap2 entries)
To do this tracking, the writable bit is cleared from PTEs when the
soft-dirty bit is. Thus, after this, when the task tries to modify a
page at some virtual address the #PF occurs and the kernel sets the
soft-dirty bit on the respective PTE.
Note, that although all the task's address space is marked as r/o after
the soft-dirty bits clear, the #PF-s that occur after that are processed
fast. This is so, since the pages are still mapped to physical memory,
and thus all the kernel does is finds this fact out and puts back
writable, dirty and soft-dirty bits on the PTE.
Another thing to note, is that when mremap moves PTEs they are marked
with soft-dirty as well, since from the user perspective mremap modifies
the virtual memory at mremap's new address.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: Glauber Costa <glommer@parallels.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-07-04 02:01:20 +04:00
|
|
|
SOFT-DIRTY PTEs
|
|
|
|
|
|
|
|
The soft-dirty is a bit on a PTE which helps to track which pages a task
|
|
|
|
writes to. In order to do this tracking one should
|
|
|
|
|
|
|
|
1. Clear soft-dirty bits from the task's PTEs.
|
|
|
|
|
|
|
|
This is done by writing "4" into the /proc/PID/clear_refs file of the
|
|
|
|
task in question.
|
|
|
|
|
|
|
|
2. Wait some time.
|
|
|
|
|
|
|
|
3. Read soft-dirty bits from the PTEs.
|
|
|
|
|
|
|
|
This is done by reading from the /proc/PID/pagemap. The bit 55 of the
|
|
|
|
64-bit qword is the soft-dirty one. If set, the respective PTE was
|
|
|
|
written to since step 1.
|
|
|
|
|
|
|
|
|
|
|
|
Internally, to do this tracking, the writable bit is cleared from PTEs
|
|
|
|
when the soft-dirty bit is cleared. So, after this, when the task tries to
|
|
|
|
modify a page at some virtual address the #PF occurs and the kernel sets
|
|
|
|
the soft-dirty bit on the respective PTE.
|
|
|
|
|
|
|
|
Note, that although all the task's address space is marked as r/o after the
|
|
|
|
soft-dirty bits clear, the #PF-s that occur after that are processed fast.
|
|
|
|
This is so, since the pages are still mapped to physical memory, and thus all
|
|
|
|
the kernel does is finds this fact out and puts both writable and soft-dirty
|
|
|
|
bits on the PTE.
|
|
|
|
|
2013-09-12 01:22:24 +04:00
|
|
|
While in most cases tracking memory changes by #PF-s is more than enough
|
|
|
|
there is still a scenario when we can lose soft dirty bits -- a task
|
|
|
|
unmaps a previously mapped memory region and then maps a new one at exactly
|
|
|
|
the same place. When unmap is called, the kernel internally clears PTE values
|
|
|
|
including soft dirty bits. To notify user space application about such
|
|
|
|
memory region renewal the kernel always marks new memory regions (and
|
|
|
|
expanded regions) as soft dirty.
|
mm: soft-dirty bits for user memory changes tracking
The soft-dirty is a bit on a PTE which helps to track which pages a task
writes to. In order to do this tracking one should
1. Clear soft-dirty bits from PTEs ("echo 4 > /proc/PID/clear_refs)
2. Wait some time.
3. Read soft-dirty bits (55'th in /proc/PID/pagemap2 entries)
To do this tracking, the writable bit is cleared from PTEs when the
soft-dirty bit is. Thus, after this, when the task tries to modify a
page at some virtual address the #PF occurs and the kernel sets the
soft-dirty bit on the respective PTE.
Note, that although all the task's address space is marked as r/o after
the soft-dirty bits clear, the #PF-s that occur after that are processed
fast. This is so, since the pages are still mapped to physical memory,
and thus all the kernel does is finds this fact out and puts back
writable, dirty and soft-dirty bits on the PTE.
Another thing to note, is that when mremap moves PTEs they are marked
with soft-dirty as well, since from the user perspective mremap modifies
the virtual memory at mremap's new address.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: Glauber Costa <glommer@parallels.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-07-04 02:01:20 +04:00
|
|
|
|
|
|
|
This feature is actively used by the checkpoint-restore project. You
|
|
|
|
can find more details about it on http://criu.org
|
|
|
|
|
|
|
|
|
|
|
|
-- Pavel Emelyanov, Apr 9, 2013
|