1 +---------------------------+
3 | PROJECT 3: VIRTUAL MEMORY |
5 +---------------------------+
9 >> Fill in the names and email addresses of your group members.
11 FirstName LastName <email@domain.example>
12 FirstName LastName <email@domain.example>
13 FirstName LastName <email@domain.example>
15 ---- PRELIMINARIES ----
17 >> If you have any preliminary comments on your submission, notes for the
18 >> TAs, or extra credit, please give them here.
20 >> Please cite any offline or online sources you consulted while
21 >> preparing your submission, other than the Pintos documentation, course
22 >> text, and lecture notes.
27 ---- DATA STRUCTURES ----
29 >> Copy here the declaration of each new or changed `struct' or `struct'
30 >> member, global or static variable, `typedef', or enumeration.
31 >> Identify the purpose of each in 25 words or less.
35 >> Describe your code for locating the frame, if any, that contains
36 >> the data of a given page.
38 >> How does your code coordinate accessed and dirty bits between
39 >> kernel and user virtual addresses that alias a single frame, or
40 >> alternatively how do you avoid the issue?
42 ---- SYNCHRONIZATION ----
44 >> When two user processes both need a new frame at the same time, how
49 >> Why did you choose the data structure(s) that you did for representing
50 >> virtual-to-physical mappings?
52 PAGING TO AND FROM DISK
53 =======================
55 ---- DATA STRUCTURES ----
57 >> Copy here the declaration of each new or changed `struct' or `struct'
58 >> member, global or static variable, `typedef', or enumeration.
59 >> Identify the purpose of each in 25 words or less.
63 >> When a frame is required but none is free, some frame must be
64 >> evicted. Describe your code for choosing a frame to evict.
66 >> When a process P obtains a frame that was previously used by a
67 >> process Q, how do you adjust the page table (and any other data
68 >> structures) to reflect the frame Q no longer has?
70 >> Explain your heuristic for deciding whether a page fault for an
71 >> invalid virtual address should cause the stack to be extended into the
74 ---- SYNCHRONIZATION ----
76 >> Explain the basics of your VM synchronization design. In particular,
77 >> explain how it prevents deadlock. (Refer to the textbook for an
78 >> explanation of the necessary conditions for deadlock.)
80 >> A page fault in process P can cause another process Q's frame to be
81 >> evicted. How do you ensure that Q cannot access or modify the page
82 >> during the eviction process? How do you avoid a race between P
83 >> evicting Q's frame and Q faulting the page back in?
85 >> Suppose a page fault in process P causes a page to be read from the
86 >> file system or swap. How do you ensure that a second process Q
87 >> cannot interfere by e.g. attempting to evict the frame while it is
88 >> still being read in?
90 >> Explain how you handle access to paged-out pages that occur during
91 >> system calls. Do you use page faults to bring in pages (as in user
92 >> programs), or do you have a mechanism for "locking" frames into
93 >> physical memory, or do you use some other design? How do you
94 >> gracefully handle attempted accesses to invalid virtual addresses?
98 >> A single lock for the whole VM system would make synchronization easy,
99 >> but limit parallelism. On the other hand, using many locks
100 >> complicates synchronization and raises the possibility for deadlock
101 >> but allows for high parallelism. Explain where your design falls
102 >> along this continuum and why you chose to design it this way.
107 ---- DATA STRUCTURES ----
109 >> Copy here the declaration of each new or changed `struct' or `struct'
110 >> member, global or static variable, `typedef', or enumeration.
111 >> Identify the purpose of each in 25 words or less.
115 >> Describe how memory mapped files integrate into your virtual memory
116 >> subsystem. Explain how the page fault and eviction processes differ
117 >> between swap pages and other pages.
119 >> Explain how you determine whether a new file mapping overlaps any
124 >> Mappings created with "mmap" have similar semantics to those of data
125 >> demand-paged from executables, except that "mmap" mappings are written
126 >> back to their original files, not to swap. This implies that much of
127 >> their implementation can be shared. Explain why your implementation
128 >> either does or does not share much of the code for the two situations.
133 Answering these questions is optional, but it will help us improve the
134 course in future quarters. Feel free to tell us anything you
135 want--these questions are just to spur your thoughts. You may also
136 choose to respond anonymously in the course evaluations at the end of
139 >> In your opinion, was this assignment, or any one of the three problems
140 >> in it, too easy or too hard? Did it take too long or too little time?
142 >> Did you find that working on a particular part of the assignment gave
143 >> you greater insight into some aspect of OS design?
145 >> Is there some particular fact or hint we should give students in
146 >> future quarters to help them solve the problems? Conversely, did you
147 >> find any of our guidance to be misleading?
149 >> Do you have any suggestions for the TAs to more effectively assist
150 >> students, either for future quarters or the remaining projects?
152 >> Any other comments?