Copy-on-write memory - Revision history

Radostin: s/do/does/g

2018-04-29T11:17:18Z

s/do/does/g

Radostin: s/himself/itself/g

2018-04-29T11:13:08Z

s/himself/itself/g

Xemul at 11:59, 2 February 2015

2015-02-02T11:59:29Z

Xemul: Categorize

2013-05-14T21:09:11Z

Categorize

Kir: crtools -> criu

2013-04-30T16:45:46Z

crtools -> criu

Xemul: Added introduction to the problem

2012-12-11T19:40:08Z

Added introduction to the problem

Kir: fixed wikipedia links

2012-10-31T06:24:22Z

fixed wikipedia links

Kir: lotsa formatting fixes

2012-10-31T06:23:19Z

lotsa formatting fixes

Avagin: Avagin moved page COW to Copy-on-write memory

2012-10-29T09:46:33Z

Avagin moved page COW to Copy-on-write memory

Avagin at 09:43, 29 October 2012

2012-10-29T09:43:30Z

@@ Line 4: / Line 4: @@
 When taking a dump of a process tree, it's totally correct to copy contents of all the anonymous private mappings independently and restore them in the same way -- just mmap and put the memory in there. But with this approach we effectively do the described memory duplication and thus increase memory usage by checkpointed and restore application.
-To fix this, criu in version 0.3 and above do special tricks.
+To fix this, criu in version 0.3 and above does special tricks.
 == How restore works to keep COW intact ==

@@ Line 1: / Line 1: @@
 == Problem ==
-Private anonymous mappings are tricky. They are declared to belong to a single process only and contain ''its'' data, but the Linux kernel optimizes the case when task calls fork() and creates a copy of himself. In this case all private anonymous mappings are "shared" between the parent and the child, but when either of them tries to modify the memory, the respective page is duplicated and the changes occur in the modifier's copy only.
+Private anonymous mappings are tricky. They are declared to belong to a single process only and contain ''its'' data, but the Linux kernel optimizes the case when task calls fork() and creates a copy of itself. In this case all private anonymous mappings are "shared" between the parent and the child, but when either of them tries to modify the memory, the respective page is duplicated and the changes occur in the modifier's copy only.
 When taking a dump of a process tree, it's totally correct to copy contents of all the anonymous private mappings independently and restore them in the same way -- just mmap and put the memory in there. But with this approach we effectively do the described memory duplication and thus increase memory usage by checkpointed and restore application.

← Older revision		Revision as of 11:59, 2 February 2015
Line 34:		Line 34:

	[[Category:Under the hood]]		[[Category:Under the hood]]
		+	[[Category:Memory]]

← Older revision		Revision as of 21:09, 14 May 2013
Line 32:		Line 32:

	{{Like}}		{{Like}}
		+
		+	[[Category:Under the hood]]

@@ Line 4: / Line 4: @@
 When taking a dump of a process tree, it's totally correct to copy contents of all the anonymous private mappings independently and restore them in the same way -- just mmap and put the memory in there. But with this approach we effectively do the described memory duplication and thus increase memory usage by checkpointed and restore application.
-To fix this, crtools in version 0.3 and above do special tricks.
+To fix this, criu in version 0.3 and above do special tricks.
 == How restore works to keep COW intact ==
@@ Line 10: / Line 10: @@
 # Which VMAs should be inherited?
-# How to avoid intersections with crtools VMAs?
+# How to avoid intersections with criu VMAs?
 The first question is not resolved completely. Now a VMA is inherited if a parent has a VMA with the same start and end addresses. This covers 99% of cases, but it doesn't work if a VMA was moved.
-The second question is more interesting. Currently crtools reserves continuous space for all private VMAs, then restores all VMAs one by one in this space. Inherited VMAs are moved from a parent space. All VMAs are sorted by start addresses.
+The second question is more interesting. Currently criu reserves continuous space for all private VMAs, then restores all VMAs one by one in this space. Inherited VMAs are moved from a parent space. All VMAs are sorted by start addresses.
 [[File:cow.png]]
-In “restorer” all crtools’ VMAs are unmapped and private VMAs are space apart. The complexity of this algorithm is linear. Now it looks simple, but I spent a few hours to find it.
+In “restorer” all criu’s VMAs are unmapped and private VMAs are space apart. The complexity of this algorithm is linear. Now it looks simple, but I spent a few hours to find it.
 {{Out|“Complexity is easy; simplicity is difficult. -Georgy Shpagin”}}

@@ Line 1: / Line 1: @@
 == How it works now ==
 === Restoring ===
-We have different ideas how to restore {{Abbr|COW|Copy-on-write}}<ref>[[mediawiki:Copy-on-write]]</ref> memory. In a moment we even thought to use {{Abbr|KSM|Kernel Shared Memory}}<ref>[[mediawiki:Kernel_SamePage_Merging_(KSM)]]</ref> for that. As result we found a good way for restoring COW memory (I guess). All {{Abbr|VMA|Virtual Memory Area}}s are restored in the same way as they were created. Here are two questions:
+We have different ideas how to restore {{Abbr|COW|Copy-on-write}}<ref>[[wikipedia:Copy-on-write]]</ref> memory. In a moment we even thought to use {{Abbr|KSM|Kernel Shared Memory}}<ref>[[wikipedia:Kernel SamePage Merging (KSM)]]</ref> for that. As result we found a good way for restoring COW memory (I guess). All {{Abbr|VMA|Virtual Memory Area}}s are restored in the same way as they were created. Here are two questions:
 # Which VMAs should be inherited?

@@ Line 1: / Line 1: @@
-=How it works now=
+== How it works now ==
-==Restoring==
+=== Restoring ===
-We have different ideas how to restore COW memory. In a moment we even thought to use KSM (Kernel Shared Memory) for that. As result we found a good way for restoring COW memory (I guess). All VMAs are restored in the same way as they were created. Here are two questions.
+We have different ideas how to restore {{Abbr|COW|Copy-on-write}}<ref>[[mediawiki:Copy-on-write]]</ref> memory. In a moment we even thought to use {{Abbr|KSM|Kernel Shared Memory}}<ref>[[mediawiki:Kernel_SamePage_Merging_(KSM)]]</ref> for that. As result we found a good way for restoring COW memory (I guess). All {{Abbr|VMA|Virtual Memory Area}}s are restored in the same way as they were created. Here are two questions:
-* Which vma-s should be inherited?
-* How to avoid intersections with crtools VMAs?
+# Which VMAs should be inherited?
 The first question is not resolved completely. Now a VMA is inherited if a parent has a VMA with the same start and end addresses. This covers 99% of cases, but it doesn't work if a VMA was moved.
-The second question is more interesting. Currently crtools reserves continuous space for all private vma-s, then restores all VMAs one by one in this space. Inherited vma-s are moved from a parent space. All vma-s are sorted by start addresses.
+The second question is more interesting. Currently crtools reserves continuous space for all private VMAs, then restores all VMAs one by one in this space. Inherited VMAs are moved from a parent space. All VMAs are sorted by start addresses.
 [[File:cow.png]]
-In “restorer” all crtools’ vma-s are unmapped and private vma-s are space apart. The complexity of this algorithm is linear. Now it looks simple, but I spent a few hours to find it.
+In “restorer” all crtools’ VMAs are unmapped and private VMAs are space apart. The complexity of this algorithm is linear. Now it looks simple, but I spent a few hours to find it.
- “Complexity is easy; simplicity is difficult. -Georgy Shpagin”
+{{Out|“Complexity is easy; simplicity is difficult. -Georgy Shpagin”}}
- “Everything should be made as simple as possible, but not more simpler. - Albert Einstein”
+{{Out|“Everything should be made as simple as possible, but not more simpler. - Albert Einstein”}}
 All VMAs and their contents are restored before forking children, so here is one more item. A parent can change some pages after forking a child, so such pages should be dropped from the child's VMA. For solving this problem bitmaps are used to mark touched pages and madvise() is used to remove extra pages.
 One more case is not handled now. COW memory are not restored if a process is reparented to init.
-KSM - [[http://en.wikipedia.org/wiki/Kernel_SamePage_Merging_(KSM) Kernel SamePage Merging]]
+== References ==
 {{Like}}

← Older revision	Revision as of 09:46, 29 October 2012
(No difference)

← Older revision		Revision as of 09:43, 29 October 2012
Line 26:		Line 26:

	KSM - [[http://en.wikipedia.org/wiki/Kernel_SamePage_Merging_(KSM) Kernel SamePage Merging]]		KSM - [[http://en.wikipedia.org/wiki/Kernel_SamePage_Merging_(KSM) Kernel SamePage Merging]]
		+
		+	{{Like}}