* Project 3 Source Files::
* Memory Terminology::
* Resource Management Overview::
-* Managing the Segment Table::
+* Managing the Supplemental Page Table::
* Managing the Frame Table::
* Managing the Swap Table::
* Managing Memory Mapped Files Back::
@node Pages
@subsubsection Pages
-A @dfn{page}, sometimes called a @dfn{virtual page}, is a contiguous
+A @dfn{page}, sometimes called a @dfn{virtual page}, is a continuous
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
@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
+frame}, is a continuous 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:
@node Swap Slots
@subsubsection Swap Slots
-A @dfn{swap slot} is a contiguous, page-size region of disk space on the
+A @dfn{swap slot} is a continuous, 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.
You will need to design the following data structures:
@table @asis
-@item Segment table
+@item Supplemental page table
Enables page fault handling by supplementing the page table.
-@xref{Managing the Segment Table}.
+@xref{Managing the Supplemental Page Table}.
@item Frame table
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
+@node Managing the Supplemental Page Table
+@subsection Managing the Supplemental Page Table
+
+The @dfn{supplemental page table} supplements the page table with
+additional data about each page. It is needed because of the
+limitations imposed by the page table's format. Such a data structure
+is often called a ``page table'' also; we add the word ``supplemental''
+to reduce confusion.
+
+The supplemental page 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 supplemental page table to find out what data should be
+there. Second, the kernel consults the supplemental page table when a
+process terminates, to decide what resources to free.
+
+You may organize the supplemental page 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 itself as an
+index to track the members of the supplemental page table. 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 supplemental page 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:
+@file{userprog/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.
+Locate the page that faulted in the supplemental page table. If the
+memory reference is valid, use the supplemental page 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
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).
+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, panic the kernel. Real OSes apply a wide range of policies to
+recover from or prevent such situations, but these policies are beyond
+the scope of this project.
The process of eviction comprises roughly the following steps:
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.
+Supplemental page table and page fault handler (@pxref{Managing the
+Supplemental Page Table}). Change @file{process.c} to record the
+necessary information in the supplemental page 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.
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
+by a user program, you can retrieve it from the @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.
+where a page fault occurs in the kernel. Since the processor only
+saves the stack pointer when an exception causes a switch from user
+to kernel mode, reading @code{esp} out of the @struct{intr_frame}
+passed to @func{page_fault} would yield an undefined value, not the
+user stack pointer. You will need to arrange another way, such as
+saving @code{esp} into @struct{thread} on the initial transition
+from user to kernel mode.
+
+You should 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.)
+The first stack page need not be allocated lazily. You can allocate
+and initialize it with the command line arguments at load time, with
+no need to wait for it to be faulted in.
All stack pages should be candidates for eviction. An evicted stack
page should be written to swap.
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,
+@code{mmap}ed 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.
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,
+process. If you carefully designed your data structures,
sharing of read-only pages should not make this part significantly
harder.
+@item How do we resume a process after we have handled a page fault?
+
+Returning from @func{page_fault} resumes the current user process
+(@pxref{Internal Interrupt Handling}).
+It will then retry the instruction to which the instruction pointer points.
+
@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
projects / pintos-anon / blobdiff