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 physical page, if any, that
  36 >> contains the data of a given virtual page.
  37
  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?
  41
  42 ---- SYNCHRONIZATION ----
  43
  44 >> When two user processes both need a new page frame at the same time,
  45 >> how 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 physical page frame is required but none is free, some page
  64 >> frame must be evicted.  Describe your code for choosing a frame to
  65 >> evict.
  66
  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
  69 >> page that faulted.
  70
  71 ---- SYNCHRONIZATION ----
  72
  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.)
  76
  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?
  81
  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?
  85
  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), or do you have a mechanism for "locking" pages into
  89 >> physical memory, or do you use some other design?  How do you
  90 >> gracefully handle attempted accesses to invalid virtual addresses?
  91
  92 ---- RATIONALE ----
  93
  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.
  99
 100                          MEMORY MAPPED FILES
 101                          ===================
 102
 103 ---- DATA STRUCTURES ----
 104
 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.
 108
 109 ---- ALGORITHMS ----
 110
 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.
 114
 115 >> Explain how you determine whether a new file mapping overlaps any
 116 >> existing segment.
 117
 118 ---- RATIONALE ----
 119
 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.
 125
 126                            SURVEY QUESTIONS
 127                            ================
 128
 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
 133 the quarter.
 134
 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?
 137
 138 >> Did you find that working on a particular part of the assignment gave
 139 >> you greater insight into some aspect of OS design?
 140
 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?
 144
 145 >> Do you have any suggestions for the TAs to more effectively assist
 146 >> students, either for future quarters or the remaining projects?
 147
 148 >> Any other comments?