pintos-os.org Git - pintos-anon/blob - doc/vm.tmpl

   1                     +---------------------------+
   2                     |           CS 140          |
   3                     | PROJECT 3: VIRTUAL MEMORY |
   4                     |      DESIGN DOCUMENT      |
   5                     +---------------------------+
   6
   7 ---- GROUP ----
   8
   9 >> Fill in the names and email addresses of your group members.
  10
  11 FirstName LastName <email@domain.example>
  12 FirstName LastName <email@domain.example>
  13 FirstName LastName <email@domain.example>
  14
  15 ---- PRELIMINARIES ----
  16
  17 >> If you have any preliminary comments on your submission, notes for the
  18 >> TAs, or extra credit, please give them here.
  19
  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.
  23
  24                         PAGE TABLE MANAGEMENT
  25                         =====================
  26
  27 ---- DATA STRUCTURES ----
  28
  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.
  32
  33 ---- ALGORITHMS ----
  34
  35 >> Describe your code for locating the frame, if any, that contains
  36 >> the data of a given page.
  37
  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?
  41
  42 ---- SYNCHRONIZATION ----
  43
  44 >> When two user processes both need a new frame at the same time, how
  45 >> are races avoided?
  46
  47 ---- RATIONALE ----
  48
  49 >> Why did you choose the data structure(s) that you did for representing
  50 >> virtual-to-physical mappings?
  51
  52                        PAGING TO AND FROM DISK
  53                        =======================
  54
  55 ---- DATA STRUCTURES ----
  56
  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.
  60
  61 ---- ALGORITHMS ----
  62
  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.
  65
  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?
  69
  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
  72 >> page that faulted.
  73
  74 ---- SYNCHRONIZATION ----
  75
  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.)
  79
  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?
  84
  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?
  89
  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?
  95
  96 ---- RATIONALE ----
  97
  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.
 103
 104                          MEMORY MAPPED FILES
 105                          ===================
 106
 107 ---- DATA STRUCTURES ----
 108
 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.
 112
 113 ---- ALGORITHMS ----
 114
 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.
 118
 119 >> Explain how you determine whether a new file mapping overlaps any
 120 >> existing segment.
 121
 122 ---- RATIONALE ----
 123
 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.
 129
 130                            SURVEY QUESTIONS
 131                            ================
 132
 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
 137 the quarter.
 138
 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?
 141
 142 >> Did you find that working on a particular part of the assignment gave
 143 >> you greater insight into some aspect of OS design?
 144
 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?
 148
 149 >> Do you have any suggestions for the TAs to more effectively assist
 150 >> students, either for future quarters or the remaining projects?
 151
 152 >> Any other comments?