 We're having some many technical difficulties on that. We are promised someone to take a look at this specifically, neither the keyboard nor the mouse works on this. So it looks like someone is already monkeying around with it. It looks like it's a brand new keyboard, so I'm not sure what's going on. So I do have a mouse. The problem is I need a keyboard to get to the website. So to pull up. Use the onscreen. I'm sorry? So you probably would use the mouse. Can I actually do that? That would be great. This might. Is this like? What the hell? Can you walk me through that? That would be great. So yeah, I do have a mouse. So OK. All I need to do is type in the stupid address. So where we don't start? Yep, OK, start. All apps. Let's just talk to him. Oh my god. Anyway, so that things are not a total loss in the meantime. By the way, Vicky, Mike, Chuck, just want to make sure that the level is exactly right. So OK, level is fine. OK, sounds good. OK, a couple comments just in the meantime, though. I can actually get started with some general announcements and administrative review on this. I assume everyone is tanned, relaxed from the white or black sand beaches up to Haiti on this, depending. So it's back to reality. And the upshot is this week, obviously, you have the midterm. I did confirm with Jeff. It will be held as scheduled this upcoming Friday. So more information will be forthcoming about that. I would expect it will be in this room unless otherwise announced on that. You may have heard that Jeff is very strict about the midterm. I would view that as a good thing for those of you who view tests as an individual as opposed to a group effort on that. So in other words, there's going to be some more information. Make sure I can guarantee you this. We're going to be carding you. So make sure that you bring your UBIT or photo ID. So the TAs are going to be checking that while the test is in progress. Also make sure that you arrive in plenty of time. Also, there will be assigned seating. Typically, you'll also have assigned tests on that. So there's going to be like a seating chart that will typically be placed outside the room on that. And make sure that you check to see wherever it is, like what the particular seat that you need to go to and that the test that you're taking, it will typically have your name and your mug shot on the back of it. So make sure that you take your own test on that. And typically also at the end of the test, pay attention to the time on that. Jeff will typically put a timer on there and saying how many minutes and seconds is left. You don't want to turn in your tests late. This is one class where that is not an idle threat. I can guarantee you on that. So in other words, budget your time on that. Just a couple of words about Jeff's test in the past. I've certainly taken them myself as a student and I've seen enough of them over the past several years on them. They're very predictable. He's not trying to trick you. His tests are neither hard nor difficult nor easy. He wants you to think on this. And this is one thing he's very upfront about it. In other words, this is not going to be a regurgitation or memorization test on that. So take a look at the material you have. I also confirmed with Jeff that everything through Wednesday will be on the midterm. So right up through this upcoming Wednesday, anything is fair game for the test itself. The other thing to keep in mind is that in terms of what he's looking for is, again, you're not simply trying to memorize facts, but he's going to want you to actually apply and think with them. In other words, he's going to ask you questions about, let's say, okay, what happens if we came out with a new piece of hardware, let's say a really fast processor or let's say we came out with, let's say, a disk drive that is much bigger. How would this impact, let's say, some of the policies in terms of, let's say, scheduling or paging or what have you? He's going to actually ask you to, let's say, occasionally, let's say, what is the best way of approaching this problem? Or let's say, doing some pros and cons. In other words, this particular approach is going to be better for this type of a situation. This other type of approach is going to be better for another situation and explain your line of reasoning on this. So again, he's going to ask you to take what's talked about in the lectures, but go beyond them. I remember, I got asked a question at one point about, well, let's say, as you know, typically, let's say when you, let's say, call the disk drive to let's say read a bunch of bytes from disk, it's a blocking operation, you know, sis read blocks. What happens if, let's say, we implemented asynchronous IO? What would that impact your program design? Because, again, there's pros and cons to that. Obviously, the asynchronous IO read operation returns immediately, but you don't have the data for that. So how are you going to design your user programs and what are some of the policies that you need to kind of consider in the kernel? That's a good, if you will, type of question that you can expect on that. There's probably going to be, typically, something involving a little bit of mechanical math in terms like, say, if you will, page table like TLB and whatnot. So in the same way, if you've taken, let's say, 341 and you know about, let's say, if you will, a cache eviction and cache hits for that class, it's going to be fairly similar for, let's say, the TLB for this class too. So, again, yeah, it looks like we've got it dead and or, as long as I can get to a website, I would be happy as a clam. Thank you. So, anyway, back to reality on this. So, again, the midterm Friday, again, look over a couple things. Look over all the lecture notes. Also, if you have not done so already, again, attendance is definitely better now than it was just before spring break. But, again, to those of you who are in video land, I please emphasize, do not try to watch 15 to 20 hours worth of lectures in the day or two before the test itself. Your mind is going to melt and you're not going to retain what you need to. So, if you do have lectures to make up, you want to do that starting like now ASAP to get those out of the way. So, look over the lectures. Look over the lecture notes and also old tests. I know as far as like his test follow a very good pattern, he's not like one year's test, if you will, is suddenly different from previous tests. You have access to all of the old tests. They're posted on the website and you can kind of see what the format is like for that. In terms of the general format, they are essentially essay tests. That seems to be kind of the trend for most operating systems classes in most universities on this. There's typically going to be a few multiple-choice questions that are right up at the beginning that are essentially police questions. If you've come to class and you've paid attention to the class, you should be getting close to a perfect score on the multiple-choice questions. But I know my year, and I believe pretty much all the other years, the multiple-choice is typically there's only like 10 of them, one point each. The bulk of the points is going to be on the essays on this. I can also say like, I certainly, myself have served as a grader. I'm probably going to be helping with grading with this. What are you graders looking for? So I can answer that. Again, first and foremost, how I approach this is in terms of we go through, we come up with a grading rubric so that we can be, if all else, consistent with the direction of the questions. What we want you to do is, again, answer the question on this. If you have a question during the test about like this is ambiguous, ask us beforehand. Don't try to make any assumptions on this. But again, we're going to be looking for can you answer it based upon what the question itself asked and what in terms of can you think, again, beyond what is explicitly stated in the test itself. So again, take a few minutes or so, look over the old exams, probably more than a few minutes because again, I would strongly suspect that Friday's exam is going to follow the leader of what previous exams have been like on that. And so again, to recap, midterm quiz on Friday, make sure that you follow, I strongly suspect there's going to be a bunch of emails, follow them to the letter in terms of when you arrive, seating, bringing your ID on that. The exam will be videotaped, so I can tell you that. Like I say, for those of you who are viewing this as an individual effort, this is all good. It's essentially meant to crack down on people who view tests as a group effort on this, which is kind of difficult anyway for a essay exam. But again, for the rest of you, I think it should only be a plus on this. And that should be all she wrote on that. So questions I can answer about the test itself. What's coming up? Procedures, style, what have you. And then again, just to recap, next week will be assignment 3.1 is due. So again, that's coming up right after the midterm. The core map assignment, there's already some post about how to get started. We had a lecture, I'm sorry, a recitation about the mechanics of assignment 3.1 the week before spring break. We're going to try to focus this week. The staff will be working on getting you some midterm review material on this. So we're not gonna be talking about assignment 3.1 this week. Next week essentially is wrap up a few days before when it's actually due. And we're gonna kind of start moving over to assignment 3.2. Again, 3.1 is not a big assignment, but I also don't want you to become falsely confident. Talk to the people who have already started it. You're gonna hit some, if you will, arithmetic issues fairly early on. Part of it is your kernel is not even gonna boot once you configure the bloomer for assignment 3. And so it's gonna take a little bit of time to work through, if you will, getting, well, how can you debug stuff when you can't even have a booting kernel on that? So allow enough time to get through with that. So again, the sooner you can get on to assignment 3.2, because I can tell you assignment 3.2 is going to be a big one. 3.1 is not bad, but 3.2, just a word of warning, it is bigger than assignment 2.2. And you only have two weeks for it. So this is something to kind of just budget in terms of your timing. If you can get started with that, so much the better. All right, now let's see here if I can actually make use of modern technology. And ooh, the mouse works. And how about that? Okay, the keyboard works too. So let's see here, swapping slides. There we go. Oh, this is so cool. All right, let's see. Onto the substance of today's class. Let's see what we can get through about this today. Essentially, what we're going to be talking about today is, if you will, what happens when you run out of memory on this? Up until now, what we've been talking about in terms of virtual memory is, well, what is virtual memory as opposed to physical memory? But we're still talking about essentially referencing, roughly speaking, the RAM chips in the system. Virtual memory, again, let me emphasize that there's a lot of reasons why we have it. We talked about, for example, security. We talked about the example that we can map a whole bunch of disparate fuel physical pages to one big, continuous virtual page on it. Another advantage of virtual memory is that we can make virtual memory map onto a lot more apparent memory than appears on the memory chips itself. You've all experienced this. Windows is kind of grinding away with a swap file or what have you on this. So let's actually talk about the mechanics of how this works. This is actually going to be directly applicable to assignment 3.3, a.k.a. swapping or eviction. It's the toughest part of the course assignments. It's going to be something that you're going to really need to think about and think about a lot. So do a lot of planning before you actually start coding on this here. Well, what happens when we do run out of memory here? Well, a couple options. The first option, kind of the easy one, and essentially, croak. We just can't handle that. So in other words, if we try to, let's say, call fork or what have you, and the operating system determines that it has no memory, we'll just return back to the user and say, I can't help you on that. Same thing goes for exact S-break, what have you. But that's not a very good option, and we want to avoid that if at all possible. So let's take advantage of, if you will, backing storage. Remember, again, back to 341. Essentially, a good mode of computer design is you have at the top few fast but very expensive types of memory, and it kind of boils down a pyramid shape to, at the bottom, is plentiful, cheap, but slow storage at the bottom. And right up at the top, we have, let's say, in CPU registers. They're at the top, and then like L1 cache, L2 cache, then mainboard memory, and then below that, the next level is the hard disk drive. And that's actually what we're going to be talking about today. You can even extend it below hard disk drive and talk about, let's say, tape backups or something like that. But this is all, if you will, of the levels, if you will, of the trade-off between time, money, if you will. So let's see, how can we actually create more space if we run out of mainboard memory on this? Well, a couple things here. We want to make sure that this appears as transparently as possible to the end user on this. Again, that's one of the nice things about virtual memory, that the end user, and indeed the end user program, doesn't have to worry about this. I, as a program, can simply refer to memory and the operating system is going to make all this magic happen behind my back. Well, how does this actually happen here? A couple things here is, essentially, the last time it behaved like memory. In other words, we thought that something was memory. And guess what? The next time I want to access this virtual address, we also want to have it somehow behave like memory too. And in between, OK, we've got to, if you will, preserve memory on this. So in other words, if I referred to, let's say, virtual address 1,000, and I stored a byte, and then let's say I, let's say, a timer fired, and let's say the operating system decided that it needed my memory, OK, behind my back, the operating system transparently, to me, is putting me to sleep. Again, think about Han Solo being stuffed into carbonite on this. So I'm in suspended animation. The operating system takes the value of virtual address 1,000, dumps it on the disk drive. Later on decides to reanimate me, OK, and takes the value that was on the hard drive, puts it back into some place in mainboard memory that now, once again, maps to virtual address 1,000 and reanimates me. As far as I'm concerned, huh, who, what, I'm like, I'm Rip Van Winkle. I think that nothing has happened, but all this stuff has happened behind my back. That's the essence of paging on this. It's great. It's magical. It can be somewhat of a pain to implement because, as you know in general, if you will, the easier things become to the end user or appear to be to the end user, it's probably going to be slightly more complicated to actually make it happen. So let's take a look at how we can actually do this here. Swapping, a.k.a. eviction, if you will. Eviction, OK, I'm using that a very sloppy expression. That's really only part of swapping here. And again, in general, what's going on here is we are using the hard disk as a backing store for what is in mainboard memory on this, all right? So what we're talking about in terms of moving stuff in and out, we are actually swapping pages from mainboard memory into, if you will, the hard drive. When I say eviction, I'm talking about typically pulling stuff. That's one of the stages. It's pulling stuff from mainboard memory and, if you will, evicting out a page so that someone else can use it. OK, and again, ultimate goal here is we want it to appear to the end user as much as possible to be like it has more memory than actually has on this. Now, it's not going to be a complete match. As you know, if you are, let's say, trying to run too many processes of memory intensive stuff on your laptop, you're going to know when it starts hitting the swap file, because guess what? The computer is going to do what? Exactly. Remember, it slows down. Remember the old thing about, if your computer is slow, well, besides getting rid of the viruses on the computer, the big fix for that is put in more memory. Does this all make sense now? Because the more memory you have, the less need the operating system has to go to disk. So swapping is great if we need it, but we want to avoid it if at all possible. Everyone clear on that distinction? We want it as a last resort backup, but we only want it as a last resort backup. We want to avoid it if at all possible on this. And I can actually say right now, one of the tough parts about assignment 3.3. Up until now, essentially, Jeff's tests have been focusing on, if you will, logic, passing the tests, getting the logic right. Hasn't really concerned much about performance. With 3.3, one of the things that you're going to need to deal with is some tough timer hurdles on this. So even if your logic is correct, there's going to be a timer running on test 161. And if you don't complete it in so and so much time, it still is a test fail. Because that's, after all, one of the points of eviction is to make sure that this works efficiently so that the end user is not simply sitting there twiddling thumbs. Because this is actually really the first part of the computer system and the project in this semester anyway, that you will actually see noticeable lag to the end user on this. Most of the time, computers are a lot faster than us. There's page faults going on probably millions of times a second in any given particular computer. But you all know it. That's why we're just asking. You know when the computer is going into swapping mode. Because at this point, there's too much going on. And the hard disk is really, at this point, kind of noticeably slow. And so that's, again, why you're going to need to deal with some timing hurdles on this. OK. So again, this problem we're talking about, we want to be as close as possible to RAM. But again, we do have some problems here. Very often, it's the exact opposite on here. Namely put, we have kind of the worst of both worlds. It feels like it's the disk, but it's as small as RAM if things are not done well. Sometimes this is unavoidable. You are simply trying to run too much on a computer. Sometimes it's because you need a memory upgrade. Sometimes it could be because you have a badly designed operating system on here. So again, speak to the support staff when it comes time to designing 3.3. All right, question so far. Talk in general about what swapping is before we get into some details. This slide actually brings up a point here. I do need to apologize. I have been sloppy in some of my lectures. I have been using the term page faults as essentially a big blob of goo that really I should have been, if you were more specific. It kind of includes, if you will, both TLB and page faults. So let's actually be a little bit more specific on this. Number one here is what happens when we have some sort of a memory related fault here. Essentially, first thing is let's say that your operating or your user program refers to a memory location that is not in the TLB. Remember we talked about this actually the week before spring break? The TLB has a series of virtual to physical address translations. And if there is not a mapping corresponding to the address you want, well, that generates a TLB fault on this. So again, I was, again, I do apologize. I was referring to both of these as page faults on this. Strictly speaking, for the purposes of swapping, we need to be a little bit more specific on this here. So again, it all faults on pages, but this is a type of faulting as opposed to let's say it was not in the TLB, so we have a fault. And then it goes to the operating system. And the operating system has to decide what to do. There was a reference to virtual address 1,000. We need to see, well, where is it in physical memory? Oh, it maps to physical address 2,000. In that case, we simply populate the TLB with a new entry and go on. That's what you're going to be doing for assignment 3.2. Maybe virtual address 1,000 doesn't refer to physical address 2,000. Maybe it refers to something on disk. That is a page fault. So essentially, let me kind of take a step back here and say, this is going to be kind of the types of states you're going to have to deal with, with implementing assignments 3.2 and 3.3. If you have a reference to a particular virtual address, well, scenario number one is there's already an entry in the TLB, and it's handled by hardware, transparently done. Everything's good. Life is good. You go on. But if it's not in the TLB, we have, number one, an option that it is still somewhere in physical memory. And we need to update the TLB. By the way, how do we know whether or not a virtual address is in physical memory? What type of a data structure do we have to check? I'm a user program. I'm referring to virtual address 1,000. We got a TLB fault on this. How do I know whether or not it refers to any physical address? I have to check what? Exactly. Page table and more specifically, the what corresponding to that virtual page. The page table, PTE, page table entry, OK. Which, remember, a page table is essentially a data structure consisting of a whole bunch of page table entries. That's going to tell you what the state is of a particular virtual page. So again, if I refer to virtual address 1,000, what's the page table entry for virtual address 1,000? It's going to tell me, yeah, it's in physical address 2,000. Or maybe, you know what, it's nowhere. It's somewhere on disk, OK. And that means that's a page fault. I have to retrieve it from, if you will, the hard disk. Or if you will, the, I should say this, there is a third option, which I'm kind of gooseing over here, which is it's neither in, if you will, physical memory, nor in hard disk. Now I have to determine whether or not, essentially, I should create it. In other words, is it a valid address? Or is it a totally invalid address? Because if I refer to virtual address 0, I can bet your dollars to donuts that it is not in my page table. Because remember, the operating system typically is going to be expecting, if you will, virtual addresses of 0s to be the result of common, if you will, programming errors. So we want to trap for these null pointers. So again, is a reference to a virtual address? Is it in the TLB? Is it in physical memory? Is it on disk? Is it a potentially valid address? Or is it potentially a completely invalid address? We have to determine that by looking at our data structures. And again, this is kind of the grovemen of assignment 3.2 and 3.3. Make sense? OK. So back to TLB and page faults on here. Essentially, TLB fault is if I refer to a virtual address and there's not an entry in the TLB, well, that's a TLB fault on this. And remember what happens when a TLB fault? Well, it's not in a TLB. So I go to the operating system. And it's the operating system that has the information about, well, what do you do in that case? And now we can see, if you will, page fault or not. So in terms of dependencies, essentially every page fault is preceded by a TLB fault. But not every TLB fault generates a page fault on that. Make sense on this? That was my subwoofer. Yes, excellent question. Did everyone hear that? When a program, let's say, is just launched, if you will. OK. The question, is that a question? Are you just confirming that that's the case? In other words? That's a question. OK, yes. OK. Because essentially, let's say we're in the midst of launching a program on this. And you're correct to assume that we don't have any entries in the TLB, at least corresponding to that. So question, will this impact the performance of the program because we're going to have a whole bunch of page faults? Yes, we will have a whole bunch of page faults. And now I will say this, because we're kind of assuming that we are implementing what we call, if you will, allocation on demand, or on-demand allocation. I talked about this in the recitation, if you will, the week before spring break. So again, take a look at the recitation slides. But this is something you will need to implement, which is allocation on demand. There's another way of handling, which is static allocation. In other words, let's say that I load program foo from disk. And let's say the program foo takes up 100k. During the load phase itself, load elf is would automatically allocate 100k or pages or what have you worth of physical memory. That's static allocation. So that when it runs, it doesn't have to do all that, if you will, TLB faulting on that. That's a pro and con. As a matter of fact, that might be a great exam question on this. Let's say compare, let's say, static allocation versus on-demand allocation on this. We already know what one of the downsides of on-demand allocation is. Namely, we get all these page faults that we have to service at the beginning here. What might be one of, let's say, the upsides of, if you will, let's say, what's one of the upsides of static allocation? We allocate everything right up front. What am I avoiding? Yeah, I'm avoiding all these page faults, right? Once I go through that initial hump, from that point forward, things go a little bit faster on this. But there's some downsides to that too, which we'll get to in just a few minutes. I can tell you static allocation is actually not going to work. It's going to be breaking on some of the first tests that Scott will run against your code on this. So let's do on that. Answer your question? OK. Most modern operating systems do do on-demand allocation. All right. OK. Oh, and everyone again. He'll be page fault. OK, swap out. OK, swapping in and swapping out. Now, I should say this. You swap out essentially, well, when do you swap out on this? Because we know when we need to swap in, when we need something. In other words, I've referenced a memory address. And that memory address, when I check my page table entry, it says that it's on disk. I've got to pull it in. But swapping out, it appears to be a little bit less, if you will, urgent on this. Because, well, why would I want to get rid of something that I am, in effect, not using? Well, I can see why it might be useful in the future. But it actually is kind of urgent, because typically, why are you swapping something out? Because, yes. The TLB is full. Ah, OK. Everyone hear that? OK, we're talking about swapping out here. OK, you're actually, OK, this is two very closely related concepts here, OK? Namely, the TLB can be full, OK? Because remember, the TLB only has 64 entries on this. And that is something that, by the way, will be checked in 3.2 on this. What happens when you fill up all 64 entries in the TLB? So you do need to have to kind of, if you will, think about how you're going to have to, if you will replace entries in the TLB. What I'm referring to here is, if you will, swapping out from memory to disk, OK? So, like, why would, because if I have a TLB that's full, what would I need to do in order to, let's say, I've used up all 64 entries here? I'm going to need to get rid of another TLB entry, OK? But I don't need to get rid of, if you will, let's say, evict a page out to disk. Does that make sense? OK, but that's good. Everyone clear on the distinction between, sometimes this gets confused here, and don't do it on the test, OK? If you will, swapping out TLB entries versus swapping out physical pages. And also, again, TLB faults versus page faults on this. It was a question, yes? Well, OK, what TLB, yeah, if you look at the TLB allocator in dumb VM, it essentially runs out of, it just picks the first 64 and then it panics, OK? Which in a real system is never going to work at all. Because you will definitely have many, many cases where you will be using more than 64 different pages in virtual memory. And you don't, because essentially what are you doing? You're saying is that you are limiting your user program to 64 times 4k, or what is that, 256k, OK? Which that means essentially any program that uses more than 256k of memory is going to panic on, if you will, dumb VM. So we definitely need to have that fixed, OK? It's not a big fix, but it's something that does need to be changed for assignment 3.2 to work. OK? So let's actually kind of talk about this. I was saying, well, what's the urgency contained in swapping out? What I'm trying to get at is the reason we swap out typically is because we are indeed under pressure because we need to swap in, OK? In other words, we're trying to pull something from disk and we need to create a physical table. Well, why did we put something on disk in the first place? Because we were probably out of memory. My guess is that condition has not really changed. So in other words, you're kind of getting a little bit of churn, if you will, of processes kind of evicting each other out here. So that's why this is typically going to be, if you will, something we need to do quickly on here. So this is the process here. OK, first off, number one is remove the translation from the TLB if it exists here. Because remember, I'm swapping out, let's say, a page that probably is being used by another process. Do I ever want to swap out my own pages? No, I want to swap out someone other process, OK? So the thing is, in order to do that, I have to at the very least make sure that the TLB for the other process is updated. And if you're taking notes, make a note of this, this is actually where you take a look at what the mechanism is in dumb VM for doing that. You'll see that it doesn't even support it. It's like this TLB shootdown stuff. But point number one is we need to adjust the TLB for the victim process. Number two is write it out to disk. Number three is update the page table. Guess what, the page table entry of the victim process again. And let's actually take a look at the graphical representation of this. Let's just say here that I have, OK, here is my particular page that I've chosen as my victim. First thing that I want to do is get rid of the TLB entry for this process. And why do I want to do this? Because if I don't do that, and then another process refers to, let's say, the virtual page 10, OK, the TLB is going to happily point it to, if you will, the same physical page. In other words, probably the physical page that I'm now using for my process on this. So this is going to result in essentially a mess. So I got to get rid of that TLB entry. Next thing I want to do is take a look at the page table entry, which currently says that blah, blah is somewhere in physical memory. I want it to be somewhere in disk instead. So what I have to do here is, blah, blah, blah, because this is the slow step. You're probably blocking on IO. And then switch the state that says that this particular virtual page is no longer in main bus memory, it is on disk. So again, general procedure here. Clear the TLB, if you will, write out to disk, update the state, yes. Question, is the TLB per processor or per system per processor? Yes? OK, definitely not, because again, translation is per CPU on this. So in other words, this is actually, this is a good question here. In terms of invalidating the entries here, what you need to do is, number one is, what is the victim process on this? And where is the victim process running on what CPU? It may not even be running at all. It may be sleeping, or maybe it's scheduled, but it's not currently running on this. So that's kind of already hints at a bit of an optimization right there. But let's say, if I'm on processor zero, and my victim process is also on processor zero, I can already take a bit of a shortcut there, because I know it ain't running, I'm running. But let's say the victim process is currently scheduled on, let's say, processor two, and let's say that it's running, well, then I'm actually going to have to give that other processor a poke. In other words, I'm going to have to generate an inter-processor interrupt. This, by the way, up until now, you have been servicing interrupts. This is now the first time in the class where you have to be concerned with directly generating an interrupt, because you are, if you will, affecting another CPU, another TLB, and another process on that. Does that answer your question? And it's running on two CPUs at once. Do you need to reach out to both of those CPUs to validate? It's whatever CPU, technically speaking, if you want to be really optimal about it, you need to pick the CPU on which the victim thread is running. Now, typically, we want to try to avoid evicting threads of our own process, but sometimes we might need to. And if we do need that, then we have to figure out, what is the victim CPU of the victim thread? Does that answer your question? So again, up until now, I should say, up till assignment 3.2, we can talk about, if you will, pages, page tables, address spaces, they are essentially per process. Because the only process that is concerned about a address space is its own process, until you get to eviction. Because now the whole point is we have a case of other processes, or in the case of a multi-threaded operating system, other threads monkeying around with my address space. So we're going to have to deal with some nasty synchronization issues on this. Yes? So the information about which process is using it and everything is stored in the core map? I'm sorry? The information about which process is using the memory and in which CPU is it stored in the core map? And how do we know that? Good point. How do we know? OK, let's say that I decide that, OK, I want to evict out, let's say, who knows this particular area in physical memory? What stores information about physical memory? Exactly. So that's going to be, if you will, my anchor between, if you will, how processes communicate with each other on this. So in some way, I'm going to have to lead breadcrumbs, if you will, from one process and one address space. And I can go through my core map to get to other processes and other address spaces on this. Correct? Hey, also I will say this, in terms of implementation, you're going to have to hold multiple locks during eviction. That is also part of the tricky part. So you have to avoid deadlocks. There was a hand raised. Oh, OK, in other words, what's the policy? In other words, what particular one to pick is my victim? Wednesday's lecture. OK, to make a long story short, that's actually one of these policy thingamabobs. There are, let's say, easy to implement, but stupid algorithms. There are tougher to implement. But more efficient algorithms. It's kind of like scheduling on this. But you can also use the past to predict the future on this. Like you can start with a simple round robin algorithm. It's easy to implement. I'll also tell you, you will not pass the time barriers with that. But it's a place to get started. There was a question over here. Well, yeah, I mean, you're going to have to, well, I guess that, yes and no, you can do a very quick clutch. And what's the easiest way of, if you will, invalidating TLBs that's that way, I don't have to keep track of everything. Let's say that I want to evict a particular page. How can I make absolutely sure, quick and dirty, atom bomb approach, that that victim page is no longer in the TLB? I can do what to what? Turn off almost, OK? But what else here? But in effect, it has almost the same effect here. And clear the TLB for what? But for what? For which CPU? All of them. Nuke them. In other words, now, it is going to be inefficient because I'm probably just evicted my own entries on this. But again, in terms of just getting your code working, this might be a quick step. In other words, if I have to evict, I nuke all the TLBs. I know for sure that there ain't going to be any bad entries in there because there ain't going to be any entries. They're gone. But again, that's going to be, again, inefficient. You want to think about how can you actually make this a little bit more efficient on that. All righty, so swap out. Again, remove copy, slow, update. OK, so page cleaning here. OK, one of the things that Jeff's trying to get at here is, can we try to speed this up a little bit? We know, for example, that we're probably going to have to evict at some point. So remember what I was saying earlier, what's the pressure in swapping out? Well, probably because we need to swap in. Maybe we can anticipate this a little bit of time. And in effect here, you know what? Let's convince ourselves that each page has a dedicated place on disk. Not too difficult because the disk is going to be a lot bigger than memory on this. And here's the key part here. During idle periods of the operating system writes data from an active memory page to the swap disk here. In other words, let's take advantage of the fact. You know, in the same way that sometimes when the CPU is blocking, we can do other stuff so that we're not wasting CPU cycles? Well, sometimes when the system is idle, can we kind of take advantage and start preemptively writing stuff out to disk on this? Now, a little bit of a caveat here. And namely, let's say, do I myself want to write out my own pages to disk? Because almost by definition, I'm doing something here. If I'm in the middle of a mathematical calculation, I don't want to block to write stuff out to disk. And even if, let's say, I'm blocking on keyboard I.O. or something like that, it's going to be tricky if you will coordinating. Let's say I write out to disk, but in the meantime, the user has typed several characters on this. So essentially what I'm trying to drive at here is the operating system as a whole wants to do this, but you're going to want to try to rather than have the, if you will, the user processes do it, have, guess what, a dedicated process to do this. Has Jeff talked about like paging daemons? So nutshell version on this is, this is what real operating systems do, is they have dedicated threads that essentially, on their own in the background, are constantly writing stuff out, writing stuff out. And that way, when the dedicated thread blocks to write stuff out, it's not blocking, if you will, the user threads on this. And we can spin up as many of these dedicated user, if you will, paging daemon threads as we need to on this. So the nice thing about this is, and actually there are people who have done this here. So if you're looking for a little bit of an extra challenge for swapping, but on the other hand, it'll make it run faster, write yourself a paging daemon on it. Because that way, if you will, when you need to evict something out to disk, guess what, it's already evicted. You will need to, in one sense, kind of keep track of which ones have been evicted out to disk and when. That's kind of a little bit of, if you will, a implementation, make it a little bit more complicated. Okay, swap in. Let's talk about the last part of this. Namely, how can we actually get stuff back into memory? We're gonna reverse to this here. Okay, first thing is we need to stop the instruction here, allocate a memory page, locate a memory page on disk, copy it. In other words, this is kind of the reverse of what we were talking about with swapping out. Let's actually see how this actually works in practice. Okay, so here is our graphical input. Let's just say that we have a reference to memory location one, oh, something. It ain't in the TLB. So immediately we have, if you will, let's say here, we need to, we have a TLB fault and the page table entry says that it's somewhere on disk. Well, in order to service this TLB fault, what I need to do is get it from disk and put it into memory here. So guess what, it goes from, excuse me, blah, blah, blah as we're reading it in. And then guess what, update the PTE state to point to someplace in main bus memory and update the TLB and now I can finally restart the instruction. Okay, at that point it will be handled transparently. So again, to recap on this, if I have a page fault, I need to check the TLB entry. It'll tell where it is. I need to grab a new space in physical memory. I need to read it in from disk and I need to update my TLB and my page table entry data structures as appropriate. Questions on this? Okay. On-demand paging. This is what I was talking about earlier. You were actually going to need to do this. Simply put is let's procrastinate as long as possible. Remember you can have static allocation or on-demand allocation. What you're gonna need to do for OS 161 is on-demand allocation here. And essentially what we're doing here is you know what? If the process says load a bunch of memory, let's say the code or what have you, I'm actually going to mark a particular area in my change tables as being reserved but I'm not actually gonna load it from disk until I need to or vice versa on this. Let's say that I expand. Let's say the heap on this. I'm not actually going to allocate the physical memory until I actually page fault on this. Now we said that one of the advantages of static allocations is that it is fast once you get through it. But there's a disadvantage of static allocation and there's a big advantage of this. Namely, we don't have to actually allocate memory unless and until we actually use it. And sometimes the point being is we'll never use it. Questions on this? Talked about if you will static versus on-demand or dynamic allocation on this. I think at this point, yeah. Demanded pages, I'll mention this. Yeah, okay, one last page and I'll let you go here. Okay, page 16 here. Demand paging here is what happens when the process executes instruction from a new code. Okay, we essentially load it in from disk and restart as needed. And the bottom of this page here, this is key here. When a user process refers to a page in memory for the first time, you need to allocate it and really, really important, make sure that you zero the bugger. Okay, because otherwise you will be leaking states about other processes and worse yet the kernel on this. So from a standpoint of both security and stability, always make sure that you zero stuff. Okay, thank you people. Wednesday, Jeff's going to be going over paging policies, midterm quiz Friday, assignment 3.1 next week.