Assignment 3 Peer Design Review Guide As with assignment 2, the goal of this activity is to give you experience in reading and understanding someone else's design document as well as to provide feedback on your own design. You should feel free to incorporate things you learn through this process into your own designs, but please be sure to cite, in your own design document, who you worked with and what aspects of your design were influenced by the interaction. BEFORE YOU LEAVE CLASS TODAY: Please complete the (short) survey here: https://docs.google.com/forms/d/1YlpAmPb4jN0UyK2rAWwAr3KXwiz6vUrqKAuBr9k4DnQ/viewform Here is how we recommend you approach the review. You may ignore the code-reading questions for now. Take about 10-15 minutes to read through the entire design. Each time you encounter something that you don't understand or something that doesn't seem quite right, make a note of it on the document. A perfectly written design document should be sufficiently clear and detailed that you could begin coding to the design. To be clear: the design review is a collaborative process designed to improve both designs. It is not a competitive process; it is not intended to become an argument over which of two designs is better. In many cases there are multiple ways to do something, all of which are quite reasonable. However, you will do your peer review partners a great service if you pinpoint areas where they are being vague. This is almost always a sign that there is either a lack of understanding or a misunderstanding about an important part of the assignment. After both teams have completed reviewing the documents, there are two different ways to move forward. The sequential version: Pick one team to "go first." Let's say you decide that the Cobras will review the Mongooses first. The Cobras should start working their way through the design and the list of issues identified, asking for clarification. We expect that both teams will be taking notes during this process -- the Cobras should be answering the questions they jotted down and the Mongooses should be making notes on parts of their design that are unclear or that need to be modified. We also expect that we'll see people drawing things on whiteboards as part of this discussion. Please be cognizant of time -- after the initial document reviews, each team will have approximately 30 to 35 minutes to review and be reviewed. We will make announcements when we expect roles to switch, but you don't want to be caught by surprise. The parallel version: Another way to do this is to progress through the design by topic, discussing each team's design for that topic. During the discussions, the process will be similar to that outlined above, but there will be more back and forth. Pick whichever approach is more appealing; if you can't decide, try the sequential approach this time. Here is a list of topics that we expect you'll cover in your reviews. Please take notes on the list below, so you can turn in two copies of this form with your assignment -- one copy is the one you construct while reviewing someone else's design and the other is the one you construct while having your design reviewed. 1. Data structures Coremap (a way to track use of physical memory) Process VAS management (page tables are part of this, but you may need other things to support process virtual addresses). Anything you may need to manage your TLB. 2. APIs Have you designed good clean interfaces to your data structures? 3. Synchronization You should have a precise synchronization plan for each of your data structures and operations in the API. 4. Kernel Initialization You will need to initialize your virtual memory system and as we discussed right before break, the ordering is tricky, so think about this. 5. TLB Fault Handling What kinds of faults must you need to handle? What do you need to do on each one? How will TLB handling interact with Page Fault handling. 6. Page Fault Handling You should have specified algorithms for selecting pages to evict and how you'll manage that, to where you will evict pages, how you will represent various page states in your page tables, etc. It's important to remember that a page that you are about to evict could be mapped in a TLB on any processor (each processor has its own TLB). Be sure to design for handling this. 7. sbrk You can now grow virtual address spaces using sbrk. How is that going to work?