This commit is contained in:
Frans Kaashoek 2019-08-01 16:52:38 -04:00
parent 62ece4b09e
commit b02ef59e14
2 changed files with 16 additions and 6 deletions

View file

@ -1,11 +1,18 @@
<h2>Programming Assignment: Copy-on-Write Fork for xv6</h2>
<html>
<head>
<title>Lab: Copy-on-Write Fork for xv6</title>
<link rel="stylesheet" href="homework.css" type="text/css" />
</head>
<body>
<h1>Lab: Copy-on-Write Fork for xv6</h2>
<p>
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.
<h3>The problem</h3>
<h2>The problem</h2>
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.
<h3>The solution</h3>
<h2>The solution</h2>
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.
<h3>The cow test program</h3>
<h2>The cow test program</h2>
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
$
</pre>
<h3>Hints</h3>
<h2>Hints</h2>
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.
</body>
</html>

View file

@ -99,7 +99,7 @@ hi</tt> working. You should get at least one page fault (and thus lazy
allocation) in the shell, and perhaps two.
<p>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:
<ul>