 We will be covering assignment 3.3 finally and hopefully we will finish 3.3 next week. Karl will give you a quick review or also answer questions and maybe start reviewing the final exam. So just to go quickly over what we've covered in 3.2, so we presented you with a page table. We said that page table maps VPN to PTEs and each process has its own page table. We refer to a single entry that store information about a virtual page as a page table entry. And what you need in a PTE is basically VPN and it's corresponding PPN permission and state and other information. So we discussed the design that you can use to design your data structure for your page table. We've recommended using link list which save on space but it's expensive on each translation. But still it will get you past 3.2 and 3.3 tests. We also talked about multi-level page table as an option for you to go this path. And we recommended that in order for you to continue passing tests up until 3.3, we do recommend that you use a four-level page table. We covered the user address space which is a set of virtual addresses that the kernel make available to the user process. Information that you need to keep in your address space, origin information, stack heap information and then the reference to your page table. We've covered the interfaces and you have an example in loadelf.c. We also covered the TLB that is used by the MMU to speed up the translation from the virtual to physical addresses. And we've said that every core has 64 entries for the TLB and each TLB entries of 64 bits divided into two 32 bits, one for the virtual address and the other for the physical address. There are some bits that you can use, some flags like TLBDirty and VelletDat are more useful now since you are in 3.3. We're going to discuss those. Then we've mentioned the VMFault flow. So whenever a VMFault happened, that means a TLBFault did happen already. So what you need to do is you need to check the fault address to see if that address is valid, falls within the defined region. If that's valid, then you need to check if you have an entry for that address in the page table. If not, you create one virtually and physically. If you have an entry, then you check if the virtual page is in memory and not on disk. If it's in memory, then you need to update the TLB. So today we're going to cover the physical page states, virtual page states, swapping, swap out, swap in, and add a space with the swapping. Then the last slides are course slides that I do recommend you going through them. We'll talk about them. So we are at the third checkpoint. The next checkpoint now will be, which is the last one Friday, May 5th. So you should already been started. So for physical page states, now this is what I'm going to present to you as the complete picture. But what you only need now, let's start with what you need with OS161, which is the free state, the fixed state, and used. So combine the dirty and clean to use. So the free state, that means the physical page is not used, it's free for the user to use. The fixed physical page, that means this page is used by the kernel and it should not be swapped out. It should remain in the memory. And then you have on the other side with, so this side is with kernel pages or whatever pages that you should not swap out. The other side is with the user pages where you can, with OS161, what you really need is only used, just like mark the physical page as used. And that's what is required you to do, but you can also implement an additional feature which is dirty and clean, which would tell you just like if, so as we said the free is a free page, fixed is a kernel page, or a page that you shouldn't swap out. The dirty page, that means that page is allocated, but the content of that page is not similar to what you have on disk, or you just allocated that page that has no actual copy on disk. So, and with the clean, that means the content of that physical page is the same as the content on the swap disk. So there is nothing to worry about. So as you can see the states here with the kernel pages, you're going to use the things going to go through the functions of free K pages and alloc K pages. With the user pages, however, things go with your function that you've implemented, the page alloc and page free. These are the user functions. So whenever a page is dirty, you need to flush what's for the difference or things now has been modified, that is in memories, then you need to make a copy on disk if you want to maintain that state, and then you can change the state of that physical page to clean. And we're going to discuss more just like how you're going to implement this. For example, you're going to use the dirty bit, which has some other usage other than just like telling if that page is read only or read write. So for the physical page states, these are the complete picture. I just like repeat that what you really need is the free fixed and the used, which combines the dirty and the clean together. So these are the states for the physical page states with the virtual page states. You have three states unmapped, mapped, swapped, and that's depending on your implementation. So unmapped means that that virtual page is not being allocated virtually and physically. Map that means the virtual page has been allocated physically, and that page is in memory. While swapped means that that virtual page has been allocated and that page is in swapped disk. It's not in memory. So these are the states and things could change based on your implementation, but this is the general idea that you should have about the physical and virtual page states. Any questions on these? Okay, so revisiting the TLV entry. Now let's discuss more additional rules that you can use the dirty bit with, but that's again not required. I'm just giving you the idea of what are the stuff that you can use the dirty bit with. So we've already told you that the dirty bit tells if that page permission is read only or read right. You can also use that dirty bit when you just like if you want to implement copy on right. And for example, set that bit into zero, which means read only because with copy on right, you basically, if you want to, let's say with AS copy, instead of copying all pages, you only refer to the original pages and then whenever a modification happens or right will happen on these pages, you then duplicate these pages. So you can set that dirty bit to zero. That means it's only read only. Whenever a VM fault happens on this page, then you need to create a duplicate page and then change the permission, make it a read right, which means the dirty bit should be switched to one, and then you can continue the writing. Or you can use it to protect clean pages. So we've said that you have clean or dirty pages. So that means if you want to implement that functionality, you can use the dirty bit for that to protect the clean pages. And you can set it to zero as long as the page is not being written to. That means whatever in memory is the same as whatever on disk. And whenever a write or VM fault happens on that, you flip that, change the state or the permission, and then permission and the state, sorry, not the permission, the TLB dirty flag. You change that and the state of that page, and you continue writing. So these are some other usage that you can use the dirty bit with, but again, not required. So with swapping, you've already covered swapping and what is swapping, why do we need it? So just like gives the user process the illusion that you have as much memory as the disk and as fast as the RAM. And we have two main interfaces, swap out, swap in, swap out. If you run out of physical pages, then you need to swap out some pages. And then swap in whenever a VM fault happens on a page that has been swapped out of memory, then you need to bring that page back from swap disk into memory and then continue. So with the swap out, what are the steps for you? You need to take with the swap out. The first thing you need to do is you need a synchronization. Why? Because, for example, if you have, let's say you need to swap out a page that belongs to another process that's currently running on another core, that means you cannot manipulate that page up until you acquire the lock for that page. Why you need that? Because now if you want to, well, you need that lock on that page so that you make sure no access happens to that page from the process that belongs to. So you acquire the synchronization primitive of that on that page and then you need to remove the translation from the TLB for that core that the process is currently running. And as we mentioned in the last recitation, that is this only required if the process that the page belongs to is currently running. And you copy the content of the memory of that page from memory to disk and then update the page table entry to indicate that this page is not currently in memory and it is in swap disk. So there are some questions that you might wonder with the swap out is where to store the page, how to notify the owner and where do I found the page later on when I want to swap in the page. So the swap storage basically, what you need to use, things are mentioned to you and sys161.configuration file. You have two disks that you only need one but you need to enable both. The comments tells you exactly what you need to do. So you should use the VFS open to open that swap disk and you should pass the file name that is mentioned here as the file name and then the read, write as the permission. Now how should we notify the owner? Notifying the owner basically now every physical page as we said if you remember that it should keep at some point we said that with the 3, Simon 3.3 you need to keep track of the owner information in the physical page. So this is how you notify the owner. You retrieve the owner and then in the page table of that owner you need to set the state of that virtual page that it is not in memory and it will be on disk. So you need to change the where is the page and the page table for that process. And now how should we found the page? So you have the swap disk and what you need to know is that the swap disk is shared between all processes. What you should do is you need to divide the swap disk into blocks the same as page size. It's going to be 4k and you should implement a data structure that keeps tracks of the blocks on the swap disk. So your data structure will basically should be able to allocate a block on disk whenever you need especially with a swap out. It should be able also to retrieve some blocks on disk whenever you want to swap in. And for that you can check the bitmap.h header. It has helper functions that you can use to implement your swap disk data structure. So that's all about swap out. Today we don't have a lot of material to cover so we're going to finish early so I'm going to allow questions after we finish. So what's left for us is swap in. So swap in happens whenever VM fault is triggered and that when the VM fault determines that the problem is a page fault which means the page is not in memory and it's in a swap disk then you should go ahead and swap in your page. So how should this happen? You should find the swap block that belongs to that page in the swap disk and then you need to allocate a page in the physical memory and that could also trigger a swap out at the same time if you don't have any free blocks in the physical memory. Then you need to copy the content from disk to memory and update the page table for that process that this page is now in memory. So that's all about swap out and swap in. A few things that you need to take note of is what are the changes that comes with swapping to the address space interfaces. So with AS copy and AS destroy you need, if you remember that we've told you that with AS copy you need to copy each and every page. We need to complete that sentence with whether the page is in memory or on swap disk. Now how should you do this? This is up to you. You can just like decide how things should go because there are several scenarios for that whether you, for example, if the page is in a swap disk are you going to bring that page into physical memory and then copy it or just like copying right away from the swap disk. So how you do this depends on your implementation. The same thing goes with AS destroy. AS destroy you need to pre each and every page and that means in memory and swap disk. So these are the changes that you need to keep in mind for your address space interfaces. And then you have these three slides that Carl created. It's really good slides. It will tell you how you should go about implementing 3.3. It will also tell you how you can get some partial credit if you couldn't complete the 3.3. So the idea is just like start expanding and writing your data structure, write the swap disk data structure routines and then you can start with a single process and if you get that running you could be able to get about around 40 points and then start expanding that into multiprocess using one CPU and then multiple process using multiple CPUs. And then once you're done with that and get your points you can add some optimization like if you want copy and write dirty clean states or just like how you would choose your page, which page should be swapped out. These stuff that you can add once you're done with your 3.3. So that's all I have for today. Any questions? So this covers basically your 3.3 and next week we might do a review on again 3.3 and Carl might start reviewing the final exam. So thanks for coming. We will be here until the end of the lecture. So if you have any questions, thanks.