Programming Assignment: Copy-on-Write Fork for xv6
+
+
+Lab: Copy-on-Write Fork for xv6
+
+
+
+
+
Lab: Copy-on-Write Fork for xv6
Your task is implement copy-on-write fork in the xv6 kernel. You are
done if your modified kernel executes both the cow and usertests
programs successfully.
-
The problem
+
The problem
The fork() system call in xv6 copies all of the parent process's
user-space memory into the child. If the parent is large, copying can
@@ -17,7 +24,7 @@ the copied pages are thrown away without ever being used. Of course,
sometimes both child and parent modify memory at the same virtual
address after a fork(), so for some pages the copying is truly needed.
-
The solution
+
The solution
The goal of copy-on-write (COW) fork() is to defer allocating and
copying physical memory pages for the child until they are actually
@@ -41,7 +48,7 @@ memory a little trickier. A given physical page may be referred to by
multiple processes' page tables, and should be freed when the last
reference disappears.
-
The cow test program
+
The cow test program
To help you test your implementation, we've provided an xv6 program
called cow (source in user/cow.c). cow runs various tests, but
@@ -80,7 +87,7 @@ ALL TESTS PASSED
$
-
Hints
+
Hints
Here's one reasonable plan of attack. Modify uvmcopy() to map the
parent's physical pages into the child, instead of allocating new
@@ -97,3 +104,6 @@ same scheme as page faults when it encounters a COW page.
It may be useful to have a way to record, for each PTE, whether it is
a COW mapping. You can use the RSW (reserved for software) bits in
the RISC-V PTE for this.
+
+
+
diff --git a/labs/lazy.html b/labs/lazy.html
index baf5f3b..9d97cab 100644
--- a/labs/lazy.html
+++ b/labs/lazy.html
@@ -99,7 +99,7 @@ hi working. You should get at least one page fault (and thus lazy
allocation) in the shell, and perhaps two.
If you have the basics working, now turn your implementation into
- one that handles the corner cases too.
+ one that handles the corner cases too: