--- /dev/null
+ +---------------------------+
+ | CS 140 |
+ | PROJECT 3: VIRTUAL MEMORY |
+ | DESIGN DOCUMENT |
+ +---------------------------+
+
+---- GROUP ----
+
+>> Fill in the names and email addresses of your group members.
+
+FirstName LastName <email@domain.example>
+FirstName LastName <email@domain.example>
+FirstName LastName <email@domain.example>
+
+---- PRELIMINARIES ----
+
+>> If you have any preliminary comments on your submission, notes for the
+>> TAs, or extra credit, please give them here.
+
+>> Please cite any offline or online sources you consulted while
+>> preparing your submission, other than the Pintos documentation, course
+>> text, and lecture notes.
+
+ PAGE TABLE MANAGEMENT
+ =====================
+
+---- DATA STRUCTURES ----
+
+>> Copy here the declaration of each new or changed `struct' or `struct'
+>> member, global or static variable, `typedef', or enumeration.
+>> Identify the purpose of each in 25 words or less.
+
+---- ALGORITHMS ----
+
+>> Describe your code for locating the physical page, if any, that
+>> contains the data of a given virtual page.
+
+>> How does your code coordinate accessed and dirty bits between kernel
+>> and user virtual addresses that alias a single physical page, or
+>> alternatively how do you avoid the issue?
+
+---- SYNCHRONIZATION ----
+
+>> When two user processes both need a new page frame at the same time,
+>> how are races avoided?
+
+---- RATIONALE ----
+
+>> Why did you choose the data structure(s) that you did for representing
+>> virtual-to-physical mappings?
+
+ PAGING TO AND FROM DISK
+ =======================
+
+---- DATA STRUCTURES ----
+
+>> Copy here the declaration of each new or changed `struct' or `struct'
+>> member, global or static variable, `typedef', or enumeration.
+>> Identify the purpose of each in 25 words or less.
+
+---- ALGORITHMS ----
+
+>> When a physical page frame is required but none is free, some page
+>> frame must be evicted. Describe your code for choosing a frame to
+>> evict.
+
+>> Explain your heuristic for deciding whether a page fault for an
+>> invalid virtual address should cause the stack to be extended into the
+>> page that faulted.
+
+---- SYNCHRONIZATION ----
+
+>> Explain the basics of your VM synchronization design. In particular,
+>> explain how it prevents deadlock. (Refer to the textbook for an
+>> explanation of the necessary conditions for deadlock.)
+
+>> A page fault in process P can cause another process Q's page frame to
+>> be evicted. How do you ensure that Q cannot access or modify the page
+>> during the eviction process? How do you avoid a race between P
+>> evicting Q's page frame and Q faulting the page back in?
+
+>> Suppose a page fault in process P causes a page to be read from disk.
+>> How do you ensure that a second process Q cannot interfere by e.g.
+>> attempting to evict the page while it is still being read in?
+
+>> Explain how you handle access to paged-out pages that occur during
+>> system calls. Do you use page faults to bring in pages (as in user
+>> programs), do you have a mechanism for "locking" pages into physical
+>> memory, etc.? How do you gracefully handle attempted accesses to
+>> invalid virtual addresses?
+
+---- RATIONALE ----
+
+>> A single lock for the whole VM system would make synchronization easy,
+>> but limit parallelism. On the other hand, using many locks
+>> complicates synchronization and raises the possibility for deadlock
+>> but allows for high parallelism. Explain where your design falls
+>> along this continuum and why you chose to design it this way.
+
+ MEMORY MAPPED FILES
+ ===================
+
+---- DATA STRUCTURES ----
+
+>> Copy here the declaration of each new or changed `struct' or `struct'
+>> member, global or static variable, `typedef', or enumeration.
+>> Identify the purpose of each in 25 words or less.
+
+---- ALGORITHMS ----
+
+>> Describe how memory mapped files integrate into your virtual memory
+>> subsystem. Explain how the page fault and eviction processes differ
+>> for swap pages and other pages.
+
+>> Explain how you determine whether a new file mapping overlaps any
+>> existing segment.
+
+---- RATIONALE ----
+
+>> Mappings created with "mmap" have similar semantics to those of data
+>> demand-paged from executables, except that "mmap" mappings are written
+>> back to their original files, not to swap. This implies that much of
+>> their implementation can be shared. Explain why your implementation
+>> either does or does not share much of the code for the two situations.
+
+ SURVEY QUESTIONS
+ ================
+
+Answering these questions is optional, but it will help us improve the
+course in future quarters. Feel free to tell us anything you
+want--these questions are just to spur your thoughts. You may also
+choose to respond anonymously in the course evaluations at the end of
+the quarter.
+
+>> In your opinion, was this assignment, or any one of the three problems
+>> in it, too easy or too hard? Did it take too long or too little time?
+
+>> Did you find that working on a particular part of the assignment gave
+>> you greater insight into some aspect of OS design?
+
+>> Is there some particular fact or hint we should give students in
+>> future quarters to help them solve the problems? Conversely, did you
+>> find any of our guidance to be misleading?
+
+>> Do you have any suggestions for the TAs to more effectively assist
+>> students, either for future quarters or the remaining projects?
+
+>> Any other comments?
projects / pintos-anon / blobdiff