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 physical page, if any, that
36 >> contains the data of a given virtual page.
38 >> How does your code coordinate accessed and dirty bits between kernel
39 >> and user virtual addresses that alias a single physical page, or
40 >> alternatively how do you avoid the issue?
42 ---- SYNCHRONIZATION ----
44 >> When two user processes both need a new page frame at the same time,
45 >> how are races avoided?
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 physical page frame is required but none is free, some page
64 >> frame must be evicted. Describe your code for choosing a frame to
67 >> Explain your heuristic for deciding whether a page fault for an
68 >> invalid virtual address should cause the stack to be extended into the
71 ---- SYNCHRONIZATION ----
73 >> Explain the basics of your VM synchronization design. In particular,
74 >> explain how it prevents deadlock. (Refer to the textbook for an
75 >> explanation of the necessary conditions for deadlock.)
77 >> A page fault in process P can cause another process Q's page frame to
78 >> be evicted. How do you ensure that Q cannot access or modify the page
79 >> during the eviction process? How do you avoid a race between P
80 >> evicting Q's page frame and Q faulting the page back in?
82 >> Suppose a page fault in process P causes a page to be read from disk.
83 >> How do you ensure that a second process Q cannot interfere by e.g.
84 >> attempting to evict the page while it is still being read in?
86 >> Explain how you handle access to paged-out pages that occur during
87 >> system calls. Do you use page faults to bring in pages (as in user
88 >> programs), do you have a mechanism for "locking" pages into physical
89 >> memory, etc.? How do you gracefully handle attempted accesses to
90 >> invalid virtual addresses?
94 >> A single lock for the whole VM system would make synchronization easy,
95 >> but limit parallelism. On the other hand, using many locks
96 >> complicates synchronization and raises the possibility for deadlock
97 >> but allows for high parallelism. Explain where your design falls
98 >> along this continuum and why you chose to design it this way.
103 ---- DATA STRUCTURES ----
105 >> Copy here the declaration of each new or changed `struct' or `struct'
106 >> member, global or static variable, `typedef', or enumeration.
107 >> Identify the purpose of each in 25 words or less.
111 >> Describe how memory mapped files integrate into your virtual memory
112 >> subsystem. Explain how the page fault and eviction processes differ
113 >> for swap pages and other pages.
115 >> Explain how you determine whether a new file mapping overlaps any
120 >> Mappings created with "mmap" have similar semantics to those of data
121 >> demand-paged from executables, except that "mmap" mappings are written
122 >> back to their original files, not to swap. This implies that much of
123 >> their implementation can be shared. Explain why your implementation
124 >> either does or does not share much of the code for the two situations.
129 Answering these questions is optional, but it will help us improve the
130 course in future quarters. Feel free to tell us anything you
131 want--these questions are just to spur your thoughts. You may also
132 choose to respond anonymously in the course evaluations at the end of
135 >> In your opinion, was this assignment, or any one of the three problems
136 >> in it, too easy or too hard? Did it take too long or too little time?
138 >> Did you find that working on a particular part of the assignment gave
139 >> you greater insight into some aspect of OS design?
141 >> Is there some particular fact or hint we should give students in
142 >> future quarters to help them solve the problems? Conversely, did you
143 >> find any of our guidance to be misleading?
145 >> Do you have any suggestions for the TAs to more effectively assist
146 >> students, either for future quarters or the remaining projects?
148 >> Any other comments?