docs: Document soft dirty behaviour for freshly created memory regions
Subsystems (2)
PATCH 1/1 docs: Document soft dirty behaviour for freshly created memory regions
--- Documentation/vm/soft-dirty.txt | 7 +++++++ 1 file changed, 7 insertions(+)
Documentation/vm/soft-dirty.txt +7 -0
@@ -28,6 +28,13 @@ This is so, since the pages are still ma the kernel does is finds this fact out and puts both writable and soft-dirty bits on the PTE. + While in most cases tracking memory changes by #PF-s is more than enough +there is still a scenario when we can loose soft dirty bit -- a task does +unmap previously mapped memory region and then maps new one exactly at the +same place. When unmap called the kernel internally clears PTEs values +including soft dirty bit. To notify user space application about such +memory region renewal the kernel always mark new memory regions (and +expanded regions) as soft dirtified. This feature is actively used by the checkpoint-restore project. You can find more details about it on http://criu.org
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Randy Dunlap
reviewerQuoted 20 lines · Cyrill Gorcunov
Signed-off-by Cyrill Gorcunov <[email protected]>Cc Pavel Emelyanov <[email protected]>Cc Andy Lutomirski <[email protected]>Cc Andrew Morton <[email protected]>Cc Matt Mackall <[email protected]>Cc Xiao Guangrong <[email protected]>Cc Marcelo Tosatti <[email protected]>Cc KOSAKI Motohiro <[email protected]>Cc Stephen Rothwell <[email protected]>Cc Peter Zijlstra <[email protected]>Cc "Aneesh Kumar K.V" <[email protected]>--- Documentation/vm/soft-dirty.txt | 7 +++++++ 1 file changed, 7 insertions(+)Index:
linux-2.6.git/Documentation/vm/soft-dirty.txt
===================================================================
Documentation/vm/soft-dirty.txt This is so, since the pages are still ma · line 31
Quoted 4 lines
Documentation/vm/soft-dirty.txt +1
-0@@ -28,6 +28,13 @@ This is so, since the pages are still ma the kernel does is finds this fact out and puts both writable and soft-dirty bits on the PTE. + While in most cases tracking memory changes by #PF-s is more than enough
enough,
Documentation/vm/soft-dirty.txt This is so, since the pages are still ma · line 32
Quoted 1 line
Documentation/vm/soft-dirty.txt +1
-0+there is still a scenario when we can loose soft dirty bit -- a task does
lose soft dirty bits -- a task
Documentation/vm/soft-dirty.txt This is so, since the pages are still ma · line 33
Quoted 1 line
Documentation/vm/soft-dirty.txt +1
-0+unmap previously mapped memory region and then maps new one exactly at the
unmaps a previously mapped memory region and then maps a new one at exactly the
Documentation/vm/soft-dirty.txt This is so, since the pages are still ma · line 34
Quoted 1 line
Documentation/vm/soft-dirty.txt +1
-0+same place. When unmap called the kernel internally clears PTEs values
When unmap is called, the kernel internally clears PTE values
Documentation/vm/soft-dirty.txt This is so, since the pages are still ma · line 35
Quoted 1 line
Documentation/vm/soft-dirty.txt +1
-0+including soft dirty bit. To notify user space application about such
bits.
Documentation/vm/soft-dirty.txt This is so, since the pages are still ma · line 36
Quoted 1 line
Documentation/vm/soft-dirty.txt +1
-0+memory region renewal the kernel always mark new memory regions (and
marks
Documentation/vm/soft-dirty.txt This is so, since the pages are still ma · line 37
Quoted 1 line
Documentation/vm/soft-dirty.txt +1
-0+expanded regions) as soft dirtified.
or: as soft dirty.
Quoted 4 lines
Documentation/vm/soft-dirty.txt +0
-1This feature is actively used by the checkpoint-restore project. You can find more details about it on http://criu.org --
Signature · 7 lines
~Randy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 3 lines · Randy Dunlap
Quoted 2 lines
+ While in most cases tracking memory changes by #PF-s is more than enough
enough,
?
For the rest -- thanks a LOT Randy, I'll update.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Randy Dunlap
reviewerQuoted 6 lines · Cyrill Gorcunov
Quoted 3 lines · Randy Dunlap
Quoted 2 lines
+ While in most cases tracking memory changes by #PF-s is more than enough
enough,
?
Long introductory phrases usually merit a comma after them.
Quoted 3 lines
For the rest -- thanks a LOT Randy, I'll update.
--
Signature · 7 lines
~Randy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 docs: Document soft dirty behaviour for freshly created memory regions, v3
Quoted 2 lines · Randy Dunlap
Long introductory phrases usually merit a comma after them.
Ah, I see, thanks!
---
From: Cyrill Gorcunov <[email protected]>
Subject: [PATCH] docs: Document soft dirty behaviour for freshly created memory regions
--- Documentation/vm/soft-dirty.txt | 7 +++++++ 1 file changed, 7 insertions(+)
Documentation/vm/soft-dirty.txt +7 -0
@@ -28,6 +28,13 @@ This is so, since the pages are still ma the kernel does is finds this fact out and puts both writable and soft-dirty bits on the PTE. + 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. This feature is actively used by the checkpoint-restore project. You can find more details about it on http://criu.org
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 docs: Document soft dirty behaviour for freshly created memory regions, v2
In reply to Randy DunlapHere is updated one, thanks again.
---
From: Cyrill Gorcunov <[email protected]>
Subject: [PATCH] docs: Document soft dirty behaviour for freshly created memory regions
--- Documentation/vm/soft-dirty.txt | 7 +++++++ 1 file changed, 7 insertions(+)
Documentation/vm/soft-dirty.txt +7 -0
@@ -28,6 +28,13 @@ This is so, since the pages are still ma the kernel does is finds this fact out and puts both writable and soft-dirty bits on the PTE. + 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. This feature is actively used by the checkpoint-restore project. You can find more details about it on http://criu.org
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 11 lines · Cyrill Gorcunov
Signed-off-by Cyrill Gorcunov <[email protected]>Cc Pavel Emelyanov <[email protected]>Cc Andy Lutomirski <[email protected]>Cc Andrew Morton <[email protected]>Cc Matt Mackall <[email protected]>Cc Xiao Guangrong <[email protected]>Cc Marcelo Tosatti <[email protected]>Cc KOSAKI Motohiro <[email protected]>Cc Stephen Rothwell <[email protected]>Cc Peter Zijlstra <[email protected]>Cc "Aneesh Kumar K.V" <[email protected]>
With that cc: list, I'll assume you do _not_ want the Documentation maintainer paying attention to it.
Rob
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 13 lines · Rob Landley
Quoted 11 lines · Cyrill Gorcunov
Signed-off-by Cyrill Gorcunov <[email protected]>Cc Pavel Emelyanov <[email protected]>Cc Andy Lutomirski <[email protected]>Cc Andrew Morton <[email protected]>Cc Matt Mackall <[email protected]>Cc Xiao Guangrong <[email protected]>Cc Marcelo Tosatti <[email protected]>Cc KOSAKI Motohiro <[email protected]>Cc Stephen Rothwell <[email protected]>Cc Peter Zijlstra <[email protected]>Cc "Aneesh Kumar K.V" <[email protected]>
Quoted 2 lines
With that cc: list, I'll assume you do _not_ want the Documentation maintainer paying attention to it.
Hmm, I must admit I don't know whis else list should be CC'ed.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>