CSE 451 - Spring 2003 Monday, May 19. Jacob Christensen & Jai Modi ---------------------------------------------------------------------------------- Point of Today's Lecture: The future may or may not be like the past. Approximation is good enough since we're just guessing anyway. ---------------------------------------------------------------------------------- ---------------------------------------------------------------------------------- Administrative Stuff: Sign up sheet for midterm 2 will be posted outside the Professor's office. The days for the midterm are next week, on Tuesday May 27, and Wednesday May 28. Each slot is 15 minutes. Topics: anything related to this course. Sign up early to avoid conflicts. ---------------------------------------------------------------------------------- LOCALITY What does locality tell us? How would you describe "Locality" in simple terms? Answer: future will be a lot like the past (in terms of time and space). Locality tells us that old information is stale, and new information is good. How can we use this property of locality to determine what will happen in the future? The best we can do is predict the future based on what we know about the past. Yet it turns out, that locality may be misleading. The future may be like the past, maybe not. Therefore, we can't get a perfect answer when predicting the future. We're just guessing anyway! We'll still be quite well off by just guessing what is likely to happen in the future. So we have seen so far... 1) The Optimal Algorithm (Belady's Algorithm) - looks into future, can't do better. 2) Random Algorithm - simple (Recall: Both are same when there is no memory or when there is infinite amount of memory.) 3) FIFO Algorithm - implemented by a Queue that has the property: SIMPLE ----- ----- ----- |old|--->| |--->|new| ----- ----- ----- Pages near the end of the Queue marked "old" are more likely to be old pages. Pages near the end of the Queue marked "new" are definitely not old. Pages that are replaced are chosen from the end marked "old". Note however, that although pages near the end marked "old" may have been in the queue a while, it is possible that it is being used frequently, and this would not really make them stale. PAGING PROCESS The Paging process really consists of 3 processes. 1) Application thread 2) Page Fault Handler 3) Cleaner Page Fault Handler = consumer (of pages) cleaner = producer (of pages) The page fault handler is a thread in the OS, waiting for a page fault to be generated. The cleaner makes free (clean) pages that can be easily reconstructed. If the cleaner makes too few free pages, then the page fault handler has to wait behind the cleaner for free pages. Dirty Page: any page that was clean, that got written. A dirty page will require more work if and when the page becomes a candidate for replacement. The page fault handler wants to use clean pages rather than dirty pages so that no information is lost. The cleaner looks for dirty pages to be replaced, writes them to disk, and sets the valid bit to 0. Thus, the cleaner also keeps a queue of pages which go from dirty to clean as they make their way to the front of the queue. ADDING SECOND CHANCE We can do better than FIFO because a page that is old might actually be very busy. Using the same FIFO queue we would like to know when an old page is referenced again. Then we can know which pages at the end of the queue are truly not being referenced. These are better candidates for replacement. Possible Implementation: Clear the reference bit when a page enters the queue. If the page makes it to the front of the queue and the reference bit is still off, it is safe to replace it. Better Implementation: The cleaner is pulling pages from the FIFO queue and moves them to a dirty or clean queue. The pages remain in the address space of the process that owns them, but they are marked invalid. So when the process attempts to access a page from the dirty or free queue, a page fault occurs, realizes that it made a mistake, and gives it back to the process (the second chance). This helps avoid an extra trip out and back to disk. LRU (Least Recently Used) Use the past as an approximation for the future, replacing the page that has not been used for the longest period of time. 1 2 <---- Most Recently Used 3 1 7 3 5 7 2 5 6 6 4 4 0 0 17 17 <----- Least Recently Used One way to implement the LRU Algorithm is to use a data structure similar to a stack. The most recently used page is at one end, and the least recently used page is at the other end. In the above example, the stack on the left is shown before page 2 is referenced. After page 2 is referenced, page 2 becomes the most recently used page, and so it is moved to the top of the stack. With this stack property (not the case with FIFO with or without second chance): As memory size increases, more pages in memory, stack increases, page fault rate decreases. As memory size decreases, less pages in memory, stack decreases, page fault rate increases. What are the challenges to implement LRU? Every time a page is referenced, you have to do something to the stack. This may turn out to be too much work, slowing down the whole process. How do we solve this problem? Go back to the point of this lecture. Locality is a LIE, LRU is only an approximation of the future anyway. A perfect LRU stack only perfectly predicts something that isn't possible to know. So why do it perfectly? LRU APPROXIMATION ALGORITHMS... Try and divide pages up into Not Recently used (NRU) pages and somewhat recently used (SRU) pages. Then we can make an big effort to replace the not recently used pages. Then most of the time we will be right replacing the least recently used page. LRU Clock Algorithm Arrange all of the pages in physical memory in a circular queue. --- --- | | | | --- --- --- --- | | | | --- --- O------> --- --- | | | | --- --- --- --- | | | | --- --- If the reference bit of a page is set when it is referenced, we can say that since the clock was created, pages with the reference bit on have been used more frequently then those who's reference bit is off. PROBLEM: Over time, all of the reference bits go to one. We need to refresh the clock. Use the hand to sweep through the clock to clear reference bits. Now pages with zero reference bits have not been referenced in the last period. These are better candidates for replacement. We use the cycle time of the clock to determine how far we look into the past. If we move the hand too quickly, we spend all the time clearing bits. If we move it too slowly, the information becomes stale. How quickly do we want to move the hand? As quickly as the demand for pages (page fault rate). --- --- | | | | --- --- --- / --- | | / | | --- / --- O------ --- --- | | | | --- --- --- --- | | | | --- --- So this seems okay when we have a megabyte of memory, we can keep the information up to date and it shouldn't take much time. But what if we have a gigabyte of memory? Even if we sweep quickly, memory is so large the reference information is stale. The problem can be solved by using two hands. The first hand will just be responsible for clearing bits. The second hand will follow and check the reference bits to see if they are still zero. Current systems usually have approximately a twenty degree angle between the hands. This encompasses about an 18th of memory at any given time. THRASHING At some point it is possible to simply run out of memory. Thrashing means the CPU is spending all of its time just trying to satisfy page faults. Consider the following case: 1 page of available physical memory Process 1 Process 2 Uses 2 pages Uses 3 pages Neither process can get work done because each needs more than the total amount of available physical memory. We have overcommitted memory and will page back and forth, making no progress. If process 1 only required 1 page of physical memory, then the process 2 should be swapped out to disk so that process 1 can run and complete. That's it for Virtual Memory. Next time: File Systems