Now that qemu is available on Solaris, don't talk about it being

[pintos-anon] / doc / vm.texi

@node Project 3--Virtual Memory
@chapter Project 3: Virtual Memory

By now you should have some familiarity with the inner workings of
Pintos.  Your
OS can properly handle multiple threads of execution with proper
synchronization, and can load multiple user programs at once.  However,
the number and size of programs that can run is limited by the machine's
main memory size.  In this assignment, you will remove that limitation.

You will build this assignment on top of the last one.  Test programs
from project 2 should also work with project 3.  You should take care to
fix any bugs in your project 2 submission before you start work on
project 3, because those bugs will most likely cause the same problems
in project 3.

You will continue to handle Pintos disks and file systems the same way
you did in the previous assignment (@pxref{Using the File System}).

The tests for project 3 (and later projects) will probably run faster if
you use the qemu emulator, e.g.@: via @code{make check
PINTOSOPTS='--qemu'}.

@menu
* Project 3 Background::        
* Project 3 Suggested Order of Implementation::  
* Project 3 Requirements::      
* Project 3 FAQ::               
@end menu

@node Project 3 Background
@section Background

@menu
* Project 3 Source Files::      
* Memory Terminology::          
* Resource Management Overview::  
* Managing the Segment Table::  
* Managing the Frame Table::    
* Managing the Swap Table::     
* Managing Memory Mapped Files Back::  
@end menu

@node Project 3 Source Files
@subsection Source Files

You will work in the @file{vm} directory for this project.  The
@file{vm} directory contains only @file{Makefile}s.  The only
change from @file{userprog} is that this new @file{Makefile} turns on
the setting @option{-DVM}.  All code you write will be in new
files or in files introduced in earlier projects.

You will probably be encountering just a few files for the first time:

@table @file
@item devices/disk.h
@itemx devices/disk.c
Provides access to the physical disk, abstracting away the rather awful
IDE interface.  You will use this interface to access the swap disk.
@end table

@node Memory Terminology
@subsection Memory Terminology

Careful definitions are needed to keep discussion of virtual memory from
being confusing.  Thus, we begin by presenting some terminology for
memory and storage.  Some of these terms should be familiar from project
2 (@pxref{Virtual Memory Layout}), but much of it is new.

@menu
* Pages::                       
* Frames::                      
* Page Tables::                 
* Swap Slots::                  
@end menu

@node Pages
@subsubsection Pages

A @dfn{page}, sometimes called a @dfn{virtual page}, is a contiguous
region of virtual memory 4,096 bytes (the @dfn{page size}) in length.  A
page must be @dfn{page-aligned}, that is, start on a virtual address
evenly divisible by the page size.  Thus, a 32-bit virtual address can
be divided into a 20-bit @dfn{page number} and a 12-bit @dfn{page
offset} (or just @dfn{offset}), like this:

@example
@group
               31               12 11        0
              +-------------------+-----------+
              |    Page Number    |   Offset  |
              +-------------------+-----------+
                       Virtual Address
@end group
@end example

Each process has an independent set of @dfn{user (virtual) pages}, which
are those pages below virtual address @code{PHYS_BASE}, typically
@t{0xc0000000} (3 GB).  The set of @dfn{kernel (virtual) pages}, on the
other hand, is global, remaining the same regardless of what thread or
process is active.  The kernel may access both user and kernel pages,
but a user process may access only its own user pages.  @xref{Virtual
Memory Layout}, for more information.

Pintos provides several useful functions for working with virtual
addresses.  @xref{Virtual Addresses}, for details.

@node Frames
@subsubsection Frames

A @dfn{frame}, sometimes called a @dfn{physical frame} or a @dfn{page
frame}, is a contiguous region of physical memory.  Like pages, frames
must be page-size and page-aligned.  Thus, a 32-bit physical address can
be divided into a 20-bit @dfn{frame number} and a 12-bit @dfn{frame
offset} (or just @dfn{offset}), like this:

@example
@group
               31               12 11        0
              +-------------------+-----------+
              |    Frame Number   |   Offset  |
              +-------------------+-----------+
                       Physical Address
@end group
@end example

The 80@var{x}86 doesn't provide any way to directly access memory at a
physical address.  Pintos works around this by mapping kernel virtual
memory directly to physical memory: the first page of kernel virtual
memory is mapped to the first frame of physical memory, the second page
to the second frame, and so on.  Thus, frames can be accessed through
kernel virtual memory.  

Pintos provides functions for translating between physical addresses and
kernel virtual addresses.  @xref{Virtual Addresses}, for details.

@node Page Tables
@subsubsection Page Tables

In Pintos, a @dfn{page table} is a data structure that the CPU uses to
translate a virtual address to a physical address, that is, from a page
to a frame.  The page table format is dictated by the 80@var{x}86
architecture.  Pintos provides page table management code in
@file{pagedir.c} (@pxref{Page Table}).

The diagram below illustrates the relationship between pages and frames.
The virtual address, on the left, consists of a page number and an
offset.  The page table translates the page number into a frame number,
which is combined with the unmodified offset to obtain the physical
address, on the right.

@example
@group
                         +----------+
        .--------------->|Page Table|-----------.
       /                 +----------+            |
   0   |  12 11 0                            0   V  12 11 0
  +---------+----+                          +---------+----+
  |Page Nr  | Ofs|                          |Frame Nr | Ofs|
  +---------+----+                          +---------+----+
   Virt Addr   |                             Phys Addr   ^
                \_______________________________________/
@end group
@end example

@node Swap Slots
@subsubsection Swap Slots

A @dfn{swap slot} is a contiguous, page-size region of disk space on the
swap disk.  Although hardware limitations dictating the placement of
slots are looser than for pages and frames, swap slots should be
page-aligned because there is no downside in doing so.

@node Resource Management Overview
@subsection Resource Management Overview

You will need to design the following data structures:

@table @asis
@item Segment table

Enables page fault handling by supplementing the page table.
@xref{Managing the Segment Table}.

@item Frame table

Allows efficient implementation of eviction policy.
@xref{Managing the Frame Table}.

@item Swap table

Tracks usage of swap slots.
@xref{Managing the Swap Table}.

@item Table of file mappings

Processes may map files into their virtual memory space.  You need a
table to track which files are mapped into which pages.
@end table

You do not necessarily need to implement four completely distinct data
structures: it may be convenient to wholly or partially merge related
resources into a unified data structure.

For each data structure, you need to determine what information each
element should contain.  You also need to decide on the data structure's
scope, either local (per-process) or global (applying to the whole
system), and how many instances are required within its scope.

To simplify your design, you may store these data structures in
non-pageable memory.  That means that you can be sure that pointers
among them will remain valid.

Possible choices of data structures include arrays, lists, bitmaps, and
hash tables.  An array is often the simplest approach, but a sparsely
populated array wastes memory.  Lists are also simple, but traversing a
long list to find a particular position wastes time.  Both arrays and
lists can be resized, but lists more efficiently support insertion and
deletion in the middle.

Pintos includes a bitmap data structure in @file{lib/kernel/bitmap.c}
and @file{lib/kernel/bitmap.h}.  A bitmap is an array of bits, each of
which can be true or false.  Bitmaps are typically used to track usage
in a set of (identical) resources: if resource @var{n} is in use, then
bit @var{n} of the bitmap is true.  Pintos bitmaps are fixed in size,
although you could extend their implementation to support resizing.

Pintos also includes a hash table data structure (@pxref{Hash Table}).
Pintos hash tables efficiently support insertions and deletions over a
wide range of table sizes.

Although more complex data structures may yield performance or other
benefits, they may also needlessly complicate your implementation.
Thus, we do not recommend implementing any advanced data structure
(e.g.@: a balanced binary tree) as part of your design.

@node Managing the Segment Table
@subsection Managing the Segment Table

The @dfn{segment table} supplements the page table with additional data
about each page.  It is required because of the limitations imposed by
the page table's format.  Such a supplementary data structure is often
called a ``page table'' also; we call it a segment table to avoid
confusion.

The segment table is used for at least two purposes.  Most importantly,
on a page fault, the kernel looks up the virtual page that faulted in
the segment table to find out what data should be there.  Second, the
kernel consults the segment table when a process terminates, to decide
what resources to free.

You may organize the segment table as you wish.  There are at least two
basic approaches to its organization: in terms of segments or in terms
of pages.  Optionally, you may use the page table as part of your
segment table design.  You will have to modify the Pintos page table
implementation in @file{pagedir.c} to do so.  We recommend this approach
for advanced students only.  @xref{Page Table Entry Format}, for more
information.

The most important user of the segment table is the page fault handler.
In project 2, a page fault always indicated a bug in the kernel or a
user program.  In project 3, this is no longer true.  Now, a page fault
might only indicate that the page must be brought in from a file or
swap.  You will have to implement a more sophisticated page fault
handler to handle these cases.  Your page fault handler, which you
should implement by modifying @func{page_fault} in
@file{threads/exception.c}, needs to do roughly the following:

@enumerate 1
@item
Locate the page that faulted in the segment table.  If the memory
reference is valid, use the segment table entry to locate the data that
goes in the page, which might be in the file system, or in a swap slot,
or it might simply be an all-zero page.  If you implement sharing, the
page's data might even already be in a page frame, but not in the page
table.

If the page is unmapped, that is, if there's no data there, or if the
page lies within kernel virtual memory, or if the access is an attempt
to write to a read-only page, then the access is invalid.  Any invalid
access terminates the process and thereby frees all of its resources.

@item
Obtain a frame to store the page.  @xref{Managing the Frame Table}, for
details.

If you implement sharing, the data you need may already be in a frame,
in which case you must be able to locate that frame.

@item
Fetch the data into the frame, by reading it from the file system or
swap, zeroing it, etc.

If you implement sharing, the page you need may already be in a frame,
in which case no action is necessary in this step.

@item
Point the page table entry for the faulting virtual address to the
physical page.  You can use the functions in @file{userprog/pagedir.c}.
@end enumerate

@node Managing the Frame Table
@subsection Managing the Frame Table

The @dfn{frame table} contains one entry for each frame that contains a
user page.  Each entry in the frame table contains a pointer to the
page, if any, that currently occupies it, and other data of your choice.
The frame table allows Pintos to efficiently implement an eviction
policy, by choosing a page to evict when no frames are free.

The frames used for user pages should be obtained from the ``user
pool,'' by calling @code{palloc_get_page(PAL_USER)}.  You must use
@code{PAL_USER} to avoid allocating from the ``kernel pool,'' which
could cause some test cases to fail unexpectedly (@pxref{Why
PAL_USER?}).  If you modify @file{palloc.c} as part of your frame table
implementation, be sure to retain the distinction between the two pools.

The most important operation on the frame table is obtaining an unused
frame.  This is easy when a frame is free.  When none is free, a frame
must be made free by evicting some page from its frame.  If no frame can
be evicted without allocating a swap slot, but swap is full, some
process must be killed to free memory (the choice of process to kill is
up to you).

The process of eviction comprises roughly the following steps:

@enumerate 1
@item
Choose a frame to evict, using your page replacement algorithm.  The
``accessed'' and ``dirty'' bits in the page table, described below, will
come in handy.

@item
Remove references to the frame from any page table that refers to it.

Unless you have implemented sharing, only a single page should refer to
a frame at any given time.

@item
If necessary, write the page to the file system or to swap.
@end enumerate

The evicted frame may then be used to store a different page.

@menu
* Accessed and Dirty Bits::     
@end menu

@node Accessed and Dirty Bits
@subsubsection Accessed and Dirty Bits

80@var{x}86 hardware provides some assistance for implementing page
replacement algorithms, through a pair of bits in the page table entry
(PTE) for each page.  On any read or write to a page, the CPU sets the
@dfn{accessed bit} to 1 in the page's PTE, and on any write, the CPU
sets the @dfn{dirty bit} to 1.  The CPU never resets these bits to 0,
but the OS may do so.

You need to be aware of @dfn{aliases}, that is, two (or more) pages that
refer to the same frame.  When an aliased frame is accessed, the
accessed and dirty bits are updated in only one page table entry (the
one for the page used for access).  The accessed and dirty bits for the
other aliases are not updated.

In Pintos, every user virtual page is aliased to its kernel virtual
page.  You must manage these aliases somehow.  For example, your code
could check and update the accessed and dirty bits for both addresses.
Alternatively, the kernel could avoid the problem by only accessing user
data through the user virtual address.

Other aliases should only arise if you implement sharing for extra
credit (@pxref{VM Extra Credit}), or if there is a bug in your code.

@xref{Page Table Accessed and Dirty Bits}, for details of the functions
to work with accessed and dirty bits.

@node Managing the Swap Table
@subsection Managing the Swap Table

The swap table tracks in-use and free swap slots.  It should allow
picking an unused swap slot for evicting a page from its frame to the
swap disk.  It should allow freeing a swap slot when its page is read
back or the process whose page was swapped is terminated.

You may use the disk on interface @code{hd1:1} as the swap disk, using
the disk interface prototyped in @code{devices/disk.h}.  From the
@file{vm/build} directory, use the command @code{pintos-mkdisk swap.dsk
@var{n}} to create an @var{n} MB swap disk named @file{swap.dsk}.
Afterward, @file{swap.dsk} will automatically be attached as
@code{hd1:1} when you run @command{pintos}.  Alternatively, you can tell
@command{pintos} to use a temporary @var{n}-MB swap disk for a single
run with @option{--swap-disk=@var{n}}.

Swap slots should be allocated lazily, that is, only when they are
actually required by eviction.  Reading data pages from the executable
and writing them to swap immediately at process startup is not lazy.
Swap slots should not be reserved to store particular pages.

Free a swap slot when its contents are read back into a frame.

@node Managing Memory Mapped Files Back
@subsection Managing Memory Mapped Files

The file system is most commonly accessed with @code{read} and
@code{write} system calls.  A secondary interface is to ``map'' the file
into virtual pages, using the @code{mmap} system call.  The program can
then use memory instructions directly on the file data.

Suppose file @file{foo} is @t{0x1000} bytes (4 kB, or one page) long.
If @file{foo} is mapped into memory starting at address @t{0x5000}, then
any memory accesses to locations @t{0x5000}@dots{}@t{0x5fff} will access
the corresponding bytes of @file{foo}.

Here's a program that uses @code{mmap} to print a file to the console.
It opens the file specified on the command line, maps it at virtual
address @t{0x10000000}, writes the mapped data to the console (fd 1),
and unmaps the file.

@example
#include <stdio.h>
#include <syscall.h>
int main (int argc UNUSED, char *argv[]) 
@{
  void *data = (void *) 0x10000000;     /* @r{Address at which to map.} */

  int fd = open (argv[1]);              /* @r{Open file.} */
  mapid_t map = mmap (fd, data);        /* @r{Map file.} */
  write (1, data, filesize (fd));       /* @r{Write file to console.} */
  munmap (map);                         /* @r{Unmap file (optional).} */
  return 0;
@}
@end example

A similar program with full error handling is included as @file{mcat.c}
in the @file{examples} directory, which also contains @file{mcp.c} as a
second example of @code{mmap}.

Your submission must be able to track what memory is used by memory
mapped files.  This is necessary to properly handle page faults in the
mapped regions and to ensure that mapped files do not overlap any other
segments within the process.

@node Project 3 Suggested Order of Implementation
@section Suggested Order of Implementation

We suggest the following initial order of implementation:

@enumerate 1
@item
Frame table (@pxref{Managing the Frame Table}).  Change @file{process.c}
to use your frame table allocator.

Do not implement swapping yet.  If you run out of frames, fail the
allocator or panic the kernel.

After this step, your kernel should still pass all the project 2 test
cases.

@item
Segment table and page fault handler (@pxref{Managing the Segment
Table}).  Change @file{process.c} to record the necessary information in
the segment table when loading an executable and setting up its stack.
Implement loading of code and data segments in the page fault handler.
For now, consider only valid accesses.

After this step, your kernel should pass all of the project 2
functionality test cases, but only some of the robustness tests.
@end enumerate

From here, you can implement stack growth, mapped files, and page
reclamation on process exit in parallel.

The next step is to implement eviction (@pxref{Managing the Frame
Table}).  Initially you could choose the page to evict randomly.  At
this point, you need to consider how to manage accessed and dirty bits
and aliasing of user and kernel pages.  Synchronization is also a
concern: how do you deal with it if process A faults on a page whose
frame process B is in the process of evicting?  Finally, implement a
eviction strategy such as the clock algorithm.

@node Project 3 Requirements
@section Requirements

This assignment is an open-ended design problem.  We are going to say as
little as possible about how to do things.  Instead we will focus on
what functionality we require your OS to support.  We will expect
you to come up with a design that makes sense.  You will have the
freedom to choose how to handle page faults, how to organize the swap
disk, how to implement paging, etc.

@menu
* Project 3 Design Document::   
* Paging::                      
* Stack Growth::                
* Memory Mapped Files::         
@end menu

@node Project 3 Design Document
@subsection Design Document

Before you turn in your project, you must copy @uref{vm.tmpl, , the
project 3 design document template} into your source tree under the name
@file{pintos/src/vm/DESIGNDOC} and fill it in.  We recommend that you
read the design document template before you start working on the
project.  @xref{Project Documentation}, for a sample design document
that goes along with a fictitious project.

@node Paging
@subsection Paging

Implement paging for segments loaded from executables.  All of these
pages should be loaded lazily, that is, only as the kernel intercepts
page faults for them.  Upon eviction, pages modified since load (e.g.@:
as indicated by the ``dirty bit'') should be written to swap.
Unmodified pages, including read-only pages, should never be written to
swap because they can always be read back from the executable.

Implement a global page replacement algorithm that approximates LRU.
Your algorithm should perform at least as well as the ``second chance''
or ``clock'' algorithm.

Your design should allow for parallelism.  If one page fault requires
I/O, in the meantime processes that do not fault should continue
executing and other page faults that do not require I/O should be able
to complete.  This will require some synchronization effort.

You'll need to modify the core of the program loader, which is the loop
in @func{load_segment} in @file{userprog/process.c}.  Each time around
the loop, @code{page_read_bytes} receives the number of bytes to read
from the executable file and @code{page_zero_bytes} receives the number
of bytes to initialize to zero following the bytes read.  The two always
sum to @code{PGSIZE} (4,096).  The handling of a page depends on these
variables' values:

@itemize @bullet
@item
If @code{page_read_bytes} equals @code{PGSIZE}, the page should be demand
paged from disk on its first access.

@item
If @code{page_zero_bytes} equals @code{PGSIZE}, the page does not need to
be read from disk at all because it is all zeroes.  You should handle
such pages by creating a new page consisting of all zeroes at the
first page fault.

@item
Otherwise, neither @code{page_read_bytes} nor @code{page_zero_bytes}
equals @code{PGSIZE}.  In this case, an initial part of the page is to
be read from disk and the remainder zeroed.
@end itemize

@node Stack Growth
@subsection Stack Growth

Implement stack growth.  In project 2, the stack was a single page at
the top of the user virtual address space, and programs were limited to
that much stack.  Now, if the stack grows past its current size,
allocate additional pages as necessary.

Allocate additional pages only if they ``appear'' to be stack accesses.
Devise a heuristic that attempts to distinguish stack accesses from
other accesses.

User programs are buggy if they write to the stack below the stack
pointer, because typical real OSes may interrupt a process at any time
to deliver a ``signal,'' which pushes data on the stack.@footnote{This rule is
common but not universal.  One modern exception is the
@uref{http://www.x86-64.org/documentation/abi.pdf, @var{x}86-64 System V
ABI}, which designates 128 bytes below the stack pointer as a ``red
zone'' that may not be modified by signal or interrupt handlers.}
However, the 80@var{x}86 @code{PUSH} instruction checks access
permissions before it adjusts the stack pointer, so it may cause a page
fault 4 bytes below the stack pointer.  (Otherwise, @code{PUSH} would
not be restartable in a straightforward fashion.)  Similarly, the
@code{PUSHA} instruction pushes 32 bytes at once, so it can fault 32
bytes below the stack pointer.

You will need to be able to obtain the current value of the user
program's stack pointer.  Within a system call or a page fault generated
by a user program, you can retrieve it from @code{esp} member of the
@struct{intr_frame} passed to @func{syscall_handler} or
@func{page_fault}, respectively.  If you verify user pointers before
accessing them (@pxref{Accessing User Memory}), these are the only cases
you need to handle.  On the other hand, if you depend on page faults to
detect invalid memory access, you will need to handle another case,
where a page fault occurs in the kernel.  Reading @code{esp} out of the
@struct{intr_frame} passed to @func{page_fault} in that case will obtain
the kernel stack pointer, not the user stack pointer.  You will need to
arrange another way, e.g.@: by saving @code{esp} into @struct{thread} on
the initial transition from user to kernel mode.

You may impose some absolute limit on stack size, as do most OSes.
Some OSes make the limit user-adjustable, e.g.@: with the
@command{ulimit} command on many Unix systems.  On many GNU/Linux systems,
the default limit is 8 MB.

The first stack page need not be allocated lazily.  You can initialize
it with the command line arguments at load time, with no need to wait
for it to be faulted in.  (Even if you did wait, the very first
instruction in the user program is likely to be one that faults in the
page.)

All stack pages should be candidates for eviction.  An evicted stack
page should be written to swap.

@node Memory Mapped Files
@subsection Memory Mapped Files

Implement memory mapped files, including the following system calls.

@deftypefn {System Call} mapid_t mmap (int @var{fd}, void *@var{addr})
Maps the file open as @var{fd} into the process's virtual address
space.  The entire file is mapped into consecutive virtual pages
starting at @var{addr}.

Your VM system must lazily load pages in @code{mmap} regions and use the
@code{mmap}'d file itself as backing store for the mapping.  That is,
evicting a page mapped by @code{mmap} writes it back to the file it was
mapped from.

If the file's length is not a multiple of @code{PGSIZE}, then some
bytes in the final mapped page ``stick out'' beyond the end of the
file.  Set these bytes to zero when the page is faulted in from disk,
and discard them when the page is written back to disk.

If successful, this function returns a ``mapping ID'' that
uniquely identifies the mapping within the process.  On failure,
it must return -1, which otherwise should not be a valid mapping id,
and the process's mappings must be unchanged.

A call to @code{mmap} may fail if the file open as @var{fd} has a
length of zero bytes.  It must fail if @var{addr} is not page-aligned
or if the range of pages mapped overlaps any existing set of mapped
pages, including the stack or pages mapped at executable load time.
It must also fail if @var{addr} is 0, because some Pintos code assumes
virtual page 0 is not mapped.  Finally, file descriptors 0 and 1,
representing console input and output, are not mappable.
@end deftypefn

@deftypefn {System Call} void munmap (mapid_t @var{mapping})
Unmaps the mapping designated by @var{mapping}, which must be a
mapping ID returned by a previous call to @code{mmap} by the same
process that has not yet been unmapped.
@end deftypefn

All mappings are implicitly unmapped when a process exits, whether via
@code{exit} or by any other means.  When a mapping is unmapped, whether
implicitly or explicitly, all pages written to by the process are
written back to the file, and pages not written must not be.  The pages
are then removed from the process's list of virtual pages.

Closing or removing a file does not unmap any of its mappings.  Once
created, a mapping is valid until @code{munmap} is called or the process
exits, following the Unix convention.  @xref{Removing an Open File}, for
more information.

If two or more processes map the same file, there is no requirement that
they see consistent data.  Unix handles this by making the two mappings
share the same physical page, but the @code{mmap} system call also has
an argument allowing the client to specify whether the page is shared or
private (i.e.@: copy-on-write).

@node Project 3 FAQ
@section FAQ

@table @b
@item How much code will I need to write?

Here's a summary of our reference solution, produced by the
@command{diffstat} program.  The final row gives total lines inserted
and deleted; a changed line counts as both an insertion and a deletion.

This summary is relative to the Pintos base code, but the reference
solution for project 3 starts from the reference solution to project 2.
@xref{Project 2 FAQ}, for the summary of project 2.

The reference solution represents just one possible solution.  Many
other solutions are also possible and many of those differ greatly from
the reference solution.  Some excellent solutions may not modify all the
files modified by the reference solution, and some may modify files not
modified by the reference solution.

@verbatim
 Makefile.build       |    4
 devices/timer.c      |   42 ++
 threads/init.c       |    5
 threads/interrupt.c  |    2
 threads/thread.c     |   31 +
 threads/thread.h     |   37 +-
 userprog/exception.c |   12
 userprog/pagedir.c   |   10
 userprog/process.c   |  319 +++++++++++++-----
 userprog/syscall.c   |  545 ++++++++++++++++++++++++++++++-
 userprog/syscall.h   |    1
 vm/frame.c           |  162 +++++++++
 vm/frame.h           |   23 +
 vm/page.c            |  297 ++++++++++++++++
 vm/page.h            |   50 ++
 vm/swap.c            |   85 ++++
 vm/swap.h            |   11
 17 files changed, 1532 insertions(+), 104 deletions(-)
@end verbatim

@item Do we need a working Project 2 to implement Project 3?

Yes.

@item What extra credit is available?
@anchor{VM Extra Credit}

You may implement sharing: when multiple processes are created that use
the same executable file, share read-only pages among those processes
instead of creating separate copies of read-only segments for each
process.  If you carefully designed your page table data structures,
sharing of read-only pages should not make this part significantly
harder.

@item Does the virtual memory system need to support data segment growth?

No.  The size of the data segment is determined by the linker.  We still
have no dynamic allocation in Pintos (although it is possible to
``fake'' it at the user level by using memory-mapped files).  Supporting
data segment growth should add little additional complexity to a
well-designed system.

@item Why should I use @code{PAL_USER} for allocating page frames?
@anchor{Why PAL_USER?}

Passing @code{PAL_USER} to @func{palloc_get_page} causes it to allocate
memory from the user pool, instead of the main kernel pool.  Running out
of pages in the user pool just causes user programs to page, but running
out of pages in the kernel pool will cause many failures because so many
kernel functions need to obtain memory.
You can layer some other allocator on top of @func{palloc_get_page} if
you like, but it should be the underlying mechanism.

Also, you can use the @option{-ul} option to @command{pintos} to limit
the size of the user pool, which makes it easy to test your VM
implementation with various user memory sizes.
@end table