Virtual Memory. Chapter 8

Transcription

1 Chapter 8 Virtual Memory What are common with paging and segmentation are that all memory addresses within a process are logical ones that can be dynamically translated into physical addresses at run time. This facilitates the need of swapping such a process in and out of different places of main memory during its course of execution. Moreover, a process is broken into a number of pieces that are not stored in adjacent memory locations, with the help of the address translation mechanism and the use of a segment, or page, table. Indeed, it is not necessary that all of the pieces of a process be in the memory at the same time, as long as the pieces containing the next instruction and its associated data are there. 1

2 A general idea To bring in a process into the memory, OS starts by bringing in only one or a few pieces, including the piece containing the start of the program. At any time, the portion that stays in the memory is refereed to as the resident set of the process. As the process continues its execution, things proceed smoothly as long as all the memory references are made to the locations included in the resident set. 2

3 What happen if the processor sees a logical address that is not in the main memory, it generates an interrupt indicating a memory access fault. Then, the OS will place this process into a Blocked state and takes control to bring in that missing page. More specifically, OS will issue a disk I/O read request, and dispatch another process to run while the I/O operation is performed. Once the needed, but missing, page is brought in, another I/O related interrupt is issued, giving control back to the OS, which will then place the blocked process back to the Ready queue. The rest is just a technical issue... 3

4 Implication 1. More processes may be maintained in the main memory. Since we will only load part of a process into the memory, there is room for parts of the other processes. This will lead to a better utilization of the processor, since it is more likely that at least one process is ready to run. 2. A process now can be larger than the memory. A programmer once had to make sure that her program is not too large, or design some sophisticated way to split the program into pieces so that they can be loaded separately into the memory. Now, she can let the OS worry about all this mess. As far as she is concerned, the memory size is no longer a problem. This potentially much larger memory exists in the hard disk, thus, it is referred to as virtual memory, in contrast to the main memory, the real memory, since a process has to run there. 4

5 Locality Although it sounds great, is the idea of virtual memory really practical? The answer is definitely yes, based on the locality principle. Over any short period of time, execution has to be confined to a small portion of a program, and access to only a small portion of its data. Hence, we only need to bring in a few pieces at a time to avoid waste of time and resource. When there is a need, we can always swap in the needed piece. To make the whole idea work, we need hardware support for paging/segmentation mechanism, and OS support for managing the movement of pages between main memory and secondary memory. 5

6 Page table again? Since only some pages are in the memory, a (P) bit is needed for each table entry in the PPT to indicate if that page is present in the memory at the moment. If it is, a frame number is provided for this loaded page. To further raise the efficiency, another modify(m) bit is included for each entry to indicate whether that page is modified since the page was last loaded. If it is not modified, then there is no need to write it back to the disk when swapped out. Other bits may be included as well, such as those for protection and/or sharing at the page level. 6

7 Address translation The basic mechanism of reading a word from memory involves the translation of a logical address, (page number, offset), into a physical one, (frame number, offset), with help of a page table. We went through this stuff in the previous chapter... Since the size of a page table varies with the number of pages of a process, a page table has to be loaded into the main memory, together with the associated process, while a register holds the starting address of such a table. This has to be done for all the processes... 7

8 A possible hardware structure The following process is essentially the same as we went through in the last chapter for the paging mechanism. Homework: Problem

9 Where is the page table? When there are lots of processes in the system, this might not be practical. For example, in the VAX architecture, each process can access to 2 31, namely, 2 GB of virtual memory. If each page is 512 bytes big, it would mean that each process could have up to 2 22 pages. Hence, each process has to be associated with a page table with this many entries, taking a huge amount of space. To overcome this problem, most virtual memory schemes actually store page tables in virtual memory, instead of main memory. Then, page tables will also be paged, in the sense that when a process is running, only part of its page table is loaded, while the rest stays in the disk. 9

10 An example In some systems, a two level structure is used to manage large page tables, including a page directory table, containing addresses of page tables. In 32 bit address machine, if each process can get to all the 4GB space, assuming byte-level addressing, and 4 KB (2 12 ) page size, then a 4 GB (2 32 ) virtual space consists of 2 20 (= 2 32 /2 12 ) pages. If each page is referred with a 4 Byte page table entry (PTE), we need a page table of size equal to = 4 MB, namely, 2 10 pages for each process. We might not want to keep all such page tables in the memory. 10

11 What do we do? We can keep this huge page table in the virtual memory, and create a root page with 2 10 PTEs, i.e., 4 KB (= ) worth, fitting in a page, to manage this page table. Is this part of the page table in memory? If not, bring it in... The root page itself stays with the process in the main memory. In this case, we need a 2 level table system: a root page, together with a second layer containing 2 10 PTE s pointing to this many pages of space. When the space is much bigger, we could extend this to a deeper directory structure. Homework: Problem

12 Example (Con d) Below shows the steps involved in address translation under this 2 level scheme. An alternative approach, called inverted page table, based on the hashing table technique is also used in practice. Homework: Problem

13 How big should be a page? In the previous example, we use 4K as the page size, so that a root table can fit in one page. In general, to decide the appropriate size of a page, we have to consider a few factors. 1. Clearly, the smaller the size is, the less the amount of internal fragmentation, thus, the better the memory utilization is. 2. But, smaller page size leads to more pages per process, i.e., a larger page table. Then, we are enforced to adopt virtual memory. This may lead to double page faults for a memory access: If the page directory segment is out, we have to bring it in, then, perhaps, the missing page as well. Hence, a larger page size is also justifiable. 13

14 3. The locality principle also plays a part, as the following chart shows: 4. Another factor is that the page fault rate also has something to do with the number of frames assigned to a process. Generally, if the page size is fixed, then the fault rate will drop as the number of frames increases, as each process can be allocated more frames. 14

15 5. The hardware design issue of page size also depends on the size of physical main memory, and program size. 6. Another complicating issue is that modern programming techniques tend to decrease the effect of locality of reference within a process. For example, OOP techniques encourage the use of many small programs and data modules, thus leading to references scattered over a large number of objects over a short period of time These issues lead to investigation of multiple page sizes, and several existing architectures actually support this new idea as we will see near the end. 15

16 OS software The design of memory management software depends on the following basic choices: Whether to use virtual memory techniques; whether to use paging, segmentation, or both; which algorithm to use to support various aspects of memory management. The decision also depends on hardware support. For example, earlier UNIX implementation did not support virtual memory because the processor did not support either paging or segmentation. Two more points: most of the OS supports virtual memory; and pure segmentation is rarely used in today s OS design. Hence, we will focus on paging. 16

17 Choice of algorithms The fetch policy decides when a page should be loaded into the main memory. Two popular alternatives are demand paging and prepaging. With demand paging, a page is brought in when a reference is made to a location within that page. Under such a policy, when a process starts, there will be a lot of page faults. But, when time goes on, more and more pages will be loaded on demand, the locality principle suggests that things will calm down. With prepaging, other pages will be brought in as well. The physical characteristics of secondary memory, mostly disk, suggest that it will be more efficient to bring in those pages that are stored contiguously, rather than brought in one at a time. This policy can be applied when a process just starts, or every time a page fault occurs. 17

18 Placement policy This policy tries to decide where in the main memory a process piece should be put. In a pure segmentation system, we have to seriously decide which one, among best-fit, firstfit, next-fit, even worst-fit, to adopt. You have thoroughly discussed them in your homework for the last chapter... For a paging based system, this issue is almost irrelevant since the address translation hardware and the main memory access hardware can perform their functions equally well for any page-frame combination. 18

19 Replacement policy This policy deals with selecting a page in memory to kick out when a new page must be brought in. The objective of any such policy should be that the page to be removed is the one least likely to be referenced in the future. Again, the locality principle suggests a relationship between recent referencing history and near-future reference predication. Thus, most policy tries to predict future behavior, based on the past behavior. One issue we have to consider is that some of the frames in the main memory might be locked, and the pages stored there can not be replaced. For example, much of the OS kernel is kept in locked frames. Also, I/O buffers and other critical information may also be locked. 19

20 Basic algorithms The optimal policy selects for replacement the page for which to the next reference is the longest. Although it is impossible to implement, it can be used as a yardstick with the collected data. The least recently used policy replaces the page that has not been used for the longest time. By the locality principle, this is the least likely referenced page in the future. This policy does nearly as well as the optimal policy, it is difficult to implement and involves with large overhead. The first-in-first-out policy treats the page frames used as a circular queue, and take things out in round-robin style. This policy is very simple, but usually performs quite poorly. 20

21 The clock policy The simplest form requires an additional bit, the use bit, with each frame. When a page is loaded into a frame for the first time, its use bit is set to 1. When the page is used again, its use bit is set to 0. From the viewpoint of the policy, all the frames are organized as a circular queue, associated with a pointer. When it is time to replace a page, if the pointer is pointing to a page with its use bit being 0, this page is replaced; otherwise, it is reset to 0, and the pointer moves to next frame. Next slide shows an example of adding in a page

22 An clock policy example Homework: Problems 8.4, 8.5 and

23 Comparison The following chart compares the operation of the four policies, assume that the order of page access is the following: 2, 3, 2, 1, 5, 2, 4, 5, 3, 2, 5, 2. 23

24 Homework Self-study the case of variable allocation with a local scope, in pp. 371 (Eighty Ed.), and answer the following questions: 1. What is a working set? 2. Why is this policy useful? 3. How is it used to guide the above policy? 4. Paraphrase the page fault frequency algorithm, after acquiring and studying the original paper(denn80b), i.e., Denning, P., Working set past and present, IEEE Trans. Software Engineering 6(1) (1980)

25 UNIX memory management UNIX is intended to be machine independent, thus its memory management scheme varies from one system to the next. Earlier versions simply used variable partitioning with no virtual memory scheme. Newer versions, such as SVR4 and Solaris 2.x, adopt paged virtual memory system. More specifically, those two systems use paging system, based on a refined clock policy, to allocate pages to processes, and to disk block buffers; and use a kernel memory allocator, based on a buddy system, to manage memory allocation for the kernel. Kernel uses a separate policy since it frequently generates and destroys smaller data structures, which are often significantly smaller than a typical page, thus a dynamic memory allocation scheme is needed. 25

26 Linux memory management The memory management system of Linux shares many features of a typical UNIX system, but does have some unique features. Since, it was designed for the 64 bit Alpha box, it adopts a three level page table structure for its paging virtual memory, and it also accommodates the 32 bit Pentinum system by shrinking the middle level directory to the minimum of only 1. It adopts the buddy system to enhance the efficiency of page-frame mapping, by essentially allocate contiguous blocks of frames to contiguous blocks of pages. It also adopts the clock replacement algorithm to replace pages for both its virtual memory and kernel memory allocation. 26

27 For the latter, it refines the algorithm by introducing slab allocation, which essentially cuts a page into much smaller allocatable chunks. On Pentinum system, the page size is 4K bytes, which can be further divided into chunks of sizes 32, 64, 128, 252, 508, 2040, and 4080 bytes. Basically, it maintains a set of linked lists, one for each size of chunks. Chunks can be split, combined, and moved between lists when size change occurs, similar to the buddy system. 27

28 Windows memory management The Windows memory management system is designed for a variety of platforms. It uses page sizes between 4K bytes to 64 bytes. Each process sees a separate 32 bit virtual space, and has 2 GB of space for itself, while all processes share a 2 GB system space. Each user space is cut into fixed-size pages, any of which can be brought into the main memory. From a user s point of view, any page will be in one of the three states: Available: not currently used. Reserved: The system has reserved space for it in the memory, but not loaded yet. Committed: The system has actually assigned space for it. The state of being reserved minimizes the space set aside for a particular process, and can quickly assign it when the need actually materializes. 28

29 Resident set management This follows the variable allocation with a local scope. When a process is first activated, it is assigned a certain number of frames of main memory as its working set. When a process wants to reference a page that is not in, one of the resident pages is swapped out and the new page is brought in. Working sets of active processes are adjusted as follows: 1) When main memory is plentiful, the virtual memory manager allows working sets to grow. Thus, even though a new page is brought in, old pages stay. 2) When main memory becomes a hot commodity, working sets start to shrink by kicking out those less recently used pages. 29