Partial mmap'd pages need not be lazy loaded.
[pintos-anon] / doc / vm.texi
index e4dfc7026d54175fcf8107aec9f9f8f4b093d13e..0f6fa4f9a95a57fcebbd1c6e02056d0bbfd9b7e9 100644 (file)
@@ -422,13 +422,6 @@ 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.  These criteria require some synchronization effort.
 
-Write your code so that we can choose a page replacement policy at
-Pintos startup time.  By default, the LRU-like algorithm must be in
-effect, but we must be able to choose random replacement by invoking
-@command{pintos} with the @option{-rndpg} option.  Passing this option
-sets @code{enable_random_paging}, declared in @file{threads/init.h}, to
-true.
-
 @node Lazy Loading
 @subsection Lazy Loading
 
@@ -528,6 +521,8 @@ 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.
+A partial page need not be lazily loaded, as in the case of a partial
+page in an executable (@pxref{Lazy Loading}).
 
 If successful, this function returns a ``mapping ID'' that
 uniquely identifies the mapping within the process.  On failure,
@@ -787,6 +782,9 @@ it:
 munmap (map);
 @end example
 
+The @command{mcp} program in @file{src/examples} shows how to copy a
+file using memory-mapped I/O.
+
 @item What if two processes map the same file into memory?
 
 There is no requirement in Pintos that the two processes see