perform at least as well as the ``second chance'' or ``clock''
algorithm.
-Your design should allow for parallelism. Multiple processes should
-be able to process page faults at once. If one page fault require
+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. These criteria require some synchronization effort.
+executing and other page faults that do not require I/O should be able
+to complete. These criteria require some synchronization effort.
@node Lazy Loading
@subsection Lazy Loading
The core of the program loader is the loop in @func{load_segment} in
@file{userprog/process.c}.
-Each time around the loop, @code{read_bytes} receives the number of
-bytes to read from the executable file and @code{zero_bytes} receives
+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{read_bytes} equals @code{PGSIZE}, the page should be demand
+If @code{page_read_bytes} equals @code{PGSIZE}, the page should be demand
paged from disk on its first access.
@item
-If @code{zero_bytes} equals @code{PGSIZE}, the page does not need to
+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
-If neither @code{read_bytes} nor @code{zero_bytes} equals
+If neither @code{page_read_bytes} nor @code{page_zero_bytes} equals
@code{PGSIZE}, then part of the page is to be read from disk and the
remainder zeroed. This is a special case. You are allowed to handle
it by reading the partial page from disk at executable load time and
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,
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.
-
-Your VM system should use the @code{mmap}'d file itself as backing
-store for the mapping. That is, to evict a page mapped by
-@code{mmap}, write it to the file it was mapped from. (In fact, you
-may choose to implement executable mappings as special, copy-on-write
-file mappings.)
@end deftypefn
@deftypefn {System Call} void munmap (mapid_t @var{mapping})