\documentstyle{article}
	
\begin{document}

\begin{flushleft}
{\Large \bf CS-230 Programming Assignment \#3: \\ Virtual Memory} \\
\vspace*{0.2in}
Due date: Monday, December 13, 1993
\end{flushleft}

\vspace{.2in}

The next phase of Nachos is to support virtual memory.
There is no new code for this assignment; your job is
to modify your implementation for the last assignment to provide
the abstraction of an (almost) unlimited virtual memory size
to each user program.  

The illusion of unlimited memory is provided by the operating system
by using main memory as a cache for the disk.
Page tables were used in the last assignment to simplify memory 
allocation and to isolate failures in one address space from 
affecting other programs.  For this assignment, page tables 
serve a few more purposes: the valid bit in the page table entry tells
the hardware which virtual pages are in memory and which are stored on disk,
and the hardware sets the use bit in the page table entry whenever
a page is referenced and the dirty bit whenever the page is modified.

When a program references a page that is not resident in memory
(detected by when the page table entry is not valid), the hardware
generates a {\em page fault} exception, trapping to the kernel.
The operating system kernel then reads the page in from disk,
sets the page table entry to point to the new page, and then resumes 
the execution of the user program.  Of course, the kernel must  
first find space in memory for the incoming page, potentially
writing some other page back to disk, if it has been modified.

As with any caching system, performance depends on the policy
used to decide which things are kept in memory and which
are only stored on disk.  
On a page fault, the kernel must decide which page to replace;
ideally, it will throw out a page that will not be referenced for 
a long time, keeping pages in memory those that are soon to be 
referenced.  Another consideration is that if the replaced page 
has been modified, the page must be first saved to disk before the needed
page can be brought in; many virtual memory systems (such as UNIX)
avoid this extra overhead by writing modified pages to disk in 
advance, so that any subsequent page faults can be completed more quickly.

\begin{description}
\item{1.}
Implement virtual memory.  For this, you will need routines
to move a page from disk to memory and from memory to disk.
Use the Nachos file system as backing store.
In order to find unreferenced pages to throw out on page faults, you may want
to keep track of all of the pages in the system which are currently
in use.  A simple way to do this is to keep a ``core map'', which
is basically a reverse page table -- instead of translating virtual
page numbers to physical pages, a core map translates physical page numbers
to the virtual pages that are stored there.

\item{2.}
Optimize the performance of your virtual memory system
in running the ``matrix'' user program.  Use as a performance
metric the number of page faults that need to go to disk.
The test case program exercises the virtual memory system by multiplying
two large matrices together.

You may alter the test program to use a different implementation of 
matrix multiply, if that helps performance, provided that it still 
correctly multiplies the matrices 
together.  Of course, you may not increase the size of main memory
in the Nachos machine emulation, although for debugging, you may want 
to decrease it.

\end{description}

\end{document}