1. Chapter 9: Virtual Memory

2. 9.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 9: Virtual Memory Chapter 9.1 Background Demand Paging Process Creation Chapter 9.2 Page Replacement Chapter 9.3 Allocation of Frames Thrashing Memory Mapped Files Chapter 9.4 Allocating Kernel Memory Demand Segmentation Operating System Examples

3. 9.3 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Background All memory management schemes attempt to have many processes in memory at the same time to support a high degree of multiprogramming. Virtual memory – is a technique that does not require the entire logical address space to be in memory for execution. Only part of the program needs to be in memory for execution. Additional parts of the address space are brought in as needed. Logical address space can therefore be much larger than physical address space. This also allows some organizations of a process’s address space to be shared by other processes. This certainly allows for more efficient process creation, as the entire address space does not need to be brought into primary memory in the beginning of execution. Virtual memory can be implemented via: Demand paging Demand segmentation

4. 9.4 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Virtual Memory That is Larger Than Physical Memory  Some basic requirements still hold: Instructions to be executed must be in physical memory. Unfortunately, this limits the size of a program to the size of memory. In truth, oftentimes major parts of programs are never executed for a given ‘run.’ Cite the 80-20 Rule…. So, the ability to execute a program only partially in memory is a great step forward. Programmers may now write programs not constrained by memory size. They may thus concentrate on the problem they’re solving rather than by limitations of the computing system. Moreso, many programs may be more readily run at the same time because entire programs need not be physically in memory at the same time. This allows more space for more ‘partial’ programs occupying memory.

5. 9.5 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Virtual Memory That is Larger Than Physical Memory  Consider this figure: We can see that only parts of a program reside in physical memory at any given snapshot in time. Other ‘parts’ of a program may reside on disk until (and if) needed. Clearly, the pages are not contiguous and a memory mapping unit (MMU) of some sort is needed to map logical pages to physical page frames in primary memory.

6. 9.6 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Virtual-Address Space Note in this figure we are allowing for a stack and a heap (as usual for an address space). Note the heap grows upward and may be used for dynamic memory allocation; Similarly the stack grows downward through successive function calls (or recursion). The large space in between is part of the virtual address space, but will require physical pages only if the heap or stack grows. Virtual address spaces that include these holes are known as sparse address spaces. (Book:) This is cool to support a enlarging stack or heap, as mentioned or if we wish to dynamically link libraries or for possibly other shared objects during execution. Virtual memory also provides for files and memory to be shared by two or more processes through page sharing. (ahead)

7. 9.7 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Shared Library Using Virtual Memory A visual on shared pages might look like this:

8. 9.8 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts 9.2 Demand Paging Programs can be brought into primary memory – totally and completely. Grossly inefficient and many programs do not need or will not execute all parts of a program for any given execution. Alternatively, we might bring a page into memory only when it is needed. Common approach called demand paging. Clearly, goals to be obtained include  Less I/O needed  Less memory needed  Faster response  More users can occupy memory Note that we now view a process as a sequence of pages rather than as one large contiguous address space. (“A ‘swapper’ manipulates entire processes, whereas a pager is concerned only with individual pages of a process.”)

9. 9.9 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Transfer of a Paged Memory to Contiguous Disk Space Page is needed  reference to it invalid reference  abort not-in-memory  bring to memory Valid page not in memory causes what we call a ‘page fault’ Much more later.

10. 9.10 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Valid-Invalid Bit With each page table entry we have a valid–invalid bit (1  in-memory, 0  not-in-memory) Valid bit = 1  associated page is both legal and is ‘in’ memory. Invalid bit (valid bit set to 0) reference is either Invalid – not in the current process’s address space, or is valid for the process, but currently still on disk. Pages table entry for the current process are either marked as invalid or contain the disk address of the page. During address translation, if valid–invalid bit in page table entry is 0  page fault

11. 9.11 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Page Table When Some Pages Are Not in Main Memory Can easily see the valid and invalid bits. Invalid pages will have no impact on the running process as long as this process does not attempt to access something in that ‘invalid’ page. Can see physical disk has pages A-F as part of the process’s pages. This snapshot says that at this instant, pages frames 0, 2, and 5 are currently memory-resident. Not valid bits too. Page 0 is mapped to frame 4; Page 2 to frame 6, and page 5 to frame 9. Other pages are not currently memory- resident.

12. 9.12 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Page Fault So what happens when an address is developed in a page that is not memory-resident? This is called a Page Fault and results in a page fault trap. If there is ever a reference to a page, first reference will trap to OS  page fault OS looks at another table inside the process’s PCB to decide if reference was: Invalid reference  abort, or Just not in memory, in which case, the OS needs to bring in the page. Steps to bringing in a page are very exacting and interesting, and form the basis for many interesting issues in the remainder of this chapter! It is worth while to go through the steps articulated in the book.

13. 9.13 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Steps in Handling a Page Fault If reference to a page was invalid, the process should abend. Period (Traps to the Operating System…). If reference was to a valid page that is simply not in memory, bring it in. Now, we must find a free frame (room for the page to be inputted) from the free- frame list Schedule a disk I/O to read page into found location (page frame). When disk I/O is complete, we must update the internal table (in PCB) retained with the process. When control returns to this process (if suspended), page table from PCB is reestablished and processing may continue. We want to restart the instruction that was interrupted by the trap. Process may now continue. (Several other issues not discussed here in this scenario…)

14. 9.14 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts What happens if there is no free frame? In this case, we must replace an existing frame. We find some page in memory, but not really in use, swap it out Algorithm is often LRU but we will discuss others later.  Page replacement constitutes an entire lecture and has many aspects to determining just how / when pages are replaced! Performance – want an algorithm which will result in minimum number of page faults Same page may be brought into memory several times during a process’s execution. Much more later on this too.

15. 9.15 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts How about a Restart After a Page Fault? When a process is suspended for, say, an I/O operation, we know that we must save the state (registers, condition codes, instruction counter, and a bunch of other things…) We must be able to restart the process at exactly the same spot where it was interrupted. Issues: If page fault occurred at instruction fetch time, no problem.  Once the required page is brought into memory and appropriate context switching, rescheduling, etc. take place, – we simply restart by fetching the instruction again and executing it. Presumably this time, the instruction is in memory in a page just brought in. If page fault occurred when we were fetching an operand, we must fetch and decode the instruction again and then fetch the operand from the newly-brought-in page.  This might occur with a simple Add X to Y.  Instruction was in memory, but operands X and Y were not!

16. 9.16 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts How about a Restart After a Page Fault - 2? What if an instruction modifies data in several locations?  Different set of problems. Example: the MVC instruction (move characters). Can move up to 256 bytes. Discuss. So what if the move straddles the current page and we encounter a page fault in moving ‘some’ of the 256 bytes to a second page? Here, the first page is partially modified. Cannot simply restart the instruction… Two solutions: 1. the instruction execution (microcode) computes and attempts to access both ends of both blocks (data from block and data to block). If a page fault is to occur, it’ll occur now.  If no page fault, move can take place  If page fault, move takes place after the needed page is loaded into memory. 2. Use temporary registers to hold values of overwritten locations.  If page fault, all the old values are written back into memory before the trap occurs  Memory is restored prior initiating the page fault routine.  But this can require a good bit of temporary register space too…

17. 9.17 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts More thoughts from Book There are other issues too… But it is important to note that paging is transparent to the user. Non-demand paging can be added to any system where a page fault represents a fatal error. This is no problem. This is easy to implement. But demand paging cannot be readily added where a page fault requires another page to be brought into memory, (perhaps room made for it), and a process restarted… There’s simply too much complexity between the CPU and the memory management routines and the hardware support required.

18. 9.18 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Performance on Demand Paging Performance issues for demand paging are very interesting and point out that as fast as our computers are, their speeds are indeed finite. And it is not just speed; it’s space and many other constraints in attempting to keep throughput high! While ‘memory access’ time itself is quite fast (10-200 nanoseconds), performance is fast – as long as there are no page faults. This is the desirable state: required pages are in memory!! Unfortunately, the larger the number of pages in memory, the less multiprogramming we have though…  There are a number of events that might need to take place in the event of a page fault. Some are probabilistic in nature and may depend on CPU scheduling! I do feel it is instructive to point out (right from your text) the myriad events that very well may occur in the event of a page fault. Let’s consider these:

19. 9.19 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Support Activities for Demand Paging A page fault may result in the following sequence executed: A trap to the operating system (page is not in memory) Save the user registers and process state in the PCB (context switching) Determine that the interrupt was a page fault Determine if the page reference was legal and then determine the location of the desired page Request a read operation from the disk into a page frame.  Wait in a I/O queue for the disk until the read can be serviced.  Wait for the device particulars to take place (seek time, latency, data transfer itself)  Transfer the page into a page frame. Depending on CPU scheduling, the CPU is likely dispatched to another process which your request for a page read is being done. Receive the interrupt from the disk I/O subsystem indicating that the I/O operation has taken place If the CPU was dispatched to another process while the I/O was being serviced, we must save the registers and process state for the other process that was executing. (context switching again) Determine that the interrupt was, in fact, from the disk I/O subsystem and not some other interrupt that causes suspension of the executing process. Correct the page table to indicate that the desired page is now in a page frame. Now, wait for the CPU to be dispatched to this process again – this may well not be immediate. When the CPU is dispatched to this process, we must restore all the general purpose registers, the process state, condition codes, new page table, and then transfer control to the interrupted statement. Whew! Unless the CPU actually awaits the fetching and loading of the requested page into memory (in response to a page fault – which is very inefficient from a CPU point of view) these are the events that will likely occur to service a page fault!

20. 9.20 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Performance of Demand Paging Servicing the page fault interrupt and restarting the process can be reduced in time to 1 to 100 mics. But it is the page switch time that can be close to 8msec! This is an incredible amount of time! This time is primarily due to the disk itself (timings for various activities required to do a retrieval) and then recognizing that this request might have been queued with other requests for access on this same disk device. Disks are normally not just sitting around awaiting a read or write request. They are kept quite busy and they too have input queues just like the CPU. Unfortunately, they are infinitely slower! Your book goes into the mathematics involved in timing page faults. Please note that we definitely want to reduce this average time in any way we can! We want to keep the page fault rate very low and have this be a very small percentage of requests in memory access.

21. 9.21 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Demand Paging Example Additional factors that can impact demand paging: 1. Typically we can have a designated swap space on disk which is much faster (has fewer lookups and more) than a typical disk I/O. Performance in demand paging can be improved by copying an entire image into the swap space at process startup and then effecting demand paging from the swap space. 2. Another option is to not write the entire image to a swap space but to initially request pages from disk as they are requested. Then, when these pages are to be replaced, write these changed pages to the swap space. Here, only needed pages are brought into memory and only additional paging will use the swap space. 3+ Other alternatives: limit the amount of swap spaced used through binary files. When a page replacement is needed, binary files can be overwritten since they are not modified). But there are constraints here too.  It is very important to note that studies have revealed that 50% of the time the page that is being replaced has been modified and therefore needs to be swapped out Thus swapping this page out (hopefully to a swap space) is required and still takes time.

22. 9.22 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Process Creation Virtual memory allows other benefits during process creation: - Copy-on-Write - Memory-Mapped Files (later)

23. 9.23 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Copy-on-Write We know that we can initiate a process by demand paging only the first page of the process needed for execution. Using the fork() system call, we can bypass the need for initial demand paging Recall that fork() creates a child that is a duplicate of the parent. Because most fork()s are followed by an exec() call, copying the parent’s address space may not be necessary. This saves considerable time and space. Copy-on-Write (COW) approach allows both parent and child processes to initially share the same pages in memory. If either process modifies a shared page, only then is the page copied Other unmodified pages are shared by parent and child. But note that all pages may not / can not be marked as copy-on-write. Clearly pages containing executable code do not qualify. Another help: a pool of zeroed out pages: Free pages here can be allocated from a pool of zeroed-out pages More details are provided in your text if you wish to learn more…

24. 9.24 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Page Replacement Page Replacement is a major topic in memory management and many factors come to bear on exactly how page replacement is implemented. Clearly, since we do not have to load all pages for a process into memory, we can increase the degree of multiprogramming because more room is available for more pages from additional processes. This may be likened to overbooking on flights in aircraft… We don’t think everyone is going to show up. If they do, we have problems, even though normally this is not the case. There are many parameters used to determine how much memory to allocate to program pages which includes space for buffers for reading / writing data from storage devices.

25. 9.25 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Page Replacement – more, but a ‘start’ When a process needs some (one or more) of its pages to be brought into memory, if there is no free space available in memory, we may well have to replace a page from some other existing process. First glances at solutions are frequently not the best: 1. terminate some process – but this reduces the amount of multiprogramming and may make the user aware of paging – something we wish to avoid. 2. We could swap out a process entirely; this too reduces multiprogramming, but facilitates the need for a page frame. So good memory management schemes demands a carefully implemented page replacement policy. We will consider several in the next presentation.

26. End of Chapter 9.1