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, lecture notes, and course staff.
  23
  24                         PAGE TABLE MANAGEMENT
  25                         =====================
  26
  27 ---- DATA STRUCTURES ----
  28
  29 >> A1: Copy here the declaration of each new or changed `struct' or
  30 >> `struct' member, global or static variable, `typedef', or
  31 >> enumeration.  Identify the purpose of each in 25 words or less.
  32
  33 ---- ALGORITHMS ----
  34
  35 >> A2: In a few paragraphs, describe your code for locating the frame,
  36 >> if any, that contains the data of a given page.
  37
  38 >> A3: 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 >> A4: When two user processes both need a new frame at the same time,
  45 >> how are races avoided?
  46
  47 ---- RATIONALE ----
  48
  49 >> A5: Why did you choose the data structure(s) that you did for
  50 >> representing virtual-to-physical mappings?
  51
  52                        PAGING TO AND FROM DISK
  53                        =======================
  54
  55 ---- DATA STRUCTURES ----
  56
  57 >> B1: Copy here the declaration of each new or changed `struct' or
  58 >> `struct' member, global or static variable, `typedef', or
  59 >> enumeration.  Identify the purpose of each in 25 words or less.
  60
  61 ---- ALGORITHMS ----
  62
  63 >> B2: 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 >> B3: 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 >> B4: Explain your heuristic for deciding whether a page fault for an
  71 >> invalid virtual address should cause the stack to be extended into
  72 >> the page that faulted.
  73
  74 ---- SYNCHRONIZATION ----
  75
  76 >> B5: Explain the basics of your VM synchronization design.  In
  77 >> particular, explain how it prevents deadlock.  (Refer to the
  78 >> textbook for an explanation of the necessary conditions for
  79 >> deadlock.)
  80
  81 >> B6: A page fault in process P can cause another process Q's frame
  82 >> to be evicted.  How do you ensure that Q cannot access or modify
  83 >> the page during the eviction process?  How do you avoid a race
  84 >> between P evicting Q's frame and Q faulting the page back in?
  85
  86 >> B7: Suppose a page fault in process P causes a page to be read from
  87 >> the file system or swap.  How do you ensure that a second process Q
  88 >> cannot interfere by e.g. attempting to evict the frame while it is
  89 >> still being read in?
  90
  91 >> B8: Explain how you handle access to paged-out pages that occur
  92 >> during system calls.  Do you use page faults to bring in pages (as
  93 >> in user programs), or do you have a mechanism for "locking" frames
  94 >> into physical memory, or do you use some other design?  How do you
  95 >> gracefully handle attempted accesses to invalid virtual addresses?
  96
  97 ---- RATIONALE ----
  98
  99 >> B9: A single lock for the whole VM system would make
 100 >> synchronization easy, but limit parallelism.  On the other hand,
 101 >> using many locks complicates synchronization and raises the
 102 >> possibility for deadlock but allows for high parallelism.  Explain
 103 >> where your design falls along this continuum and why you chose to
 104 >> design it this way.
 105
 106                          MEMORY MAPPED FILES
 107                          ===================
 108
 109 ---- DATA STRUCTURES ----
 110
 111 >> C1: Copy here the declaration of each new or changed `struct' or
 112 >> `struct' member, global or static variable, `typedef', or
 113 >> enumeration.  Identify the purpose of each in 25 words or less.
 114
 115 ---- ALGORITHMS ----
 116
 117 >> C2: Describe how memory mapped files integrate into your virtual
 118 >> memory subsystem.  Explain how the page fault and eviction
 119 >> processes differ between swap pages and other pages.
 120
 121 >> C3: Explain how you determine whether a new file mapping overlaps
 122 >> any existing segment.
 123
 124 ---- RATIONALE ----
 125
 126 >> C4: Mappings created with "mmap" have similar semantics to those of
 127 >> data demand-paged from executables, except that "mmap" mappings are
 128 >> written back to their original files, not to swap.  This implies
 129 >> that much of their implementation can be shared.  Explain why your
 130 >> implementation either does or does not share much of the code for
 131 >> the two situations.
 132
 133                            SURVEY QUESTIONS
 134                            ================
 135
 136 Answering these questions is optional, but it will help us improve the
 137 course in future quarters.  Feel free to tell us anything you
 138 want--these questions are just to spur your thoughts.  You may also
 139 choose to respond anonymously in the course evaluations at the end of
 140 the quarter.
 141
 142 >> In your opinion, was this assignment, or any one of the three problems
 143 >> in it, too easy or too hard?  Did it take too long or too little time?
 144
 145 >> Did you find that working on a particular part of the assignment gave
 146 >> you greater insight into some aspect of OS design?
 147
 148 >> Is there some particular fact or hint we should give students in
 149 >> future quarters to help them solve the problems?  Conversely, did you
 150 >> find any of our guidance to be misleading?
 151
 152 >> Do you have any suggestions for the TAs to more effectively assist
 153 >> students, either for future quarters or the remaining projects?
 154
 155 >> Any other comments?