Paging: Introduction

1 18 Paging: IntroductionIt is sometimes said that the operating system takes one of two approacheswhen solving most any space-management problem. The first approachis to chop things up intovariable-sizedpieces, as we saw withsegmenta-tionin virtual memory. Unfortunately, this solution has inherent difficul-ties. In particular, when dividing a space into different-size chunks, thespace itself can becomefragmented, and thus allocation becomes morechallenging over , it may be worth considering the second approach: to chop upspace intofixed-sizedpieces. In virtual memory, we call this ideapaging,and it goes back to an early and important system, the Atlas [KE+62, L78].

2 Instead of splitting up a process s address space into some number ofvariable-sized logical segments ( , code, heap, stack), we divide it intofixed-sized units, each of which we call apage. Correspondingly, we viewphysical memory as an array of fixed-sized slots calledpage frames; eachof these frames can contain a single virtual-memory page. Our challenge:THECRUX:HOWTOVIRTUALIZEMEMORYW ITHPAGESHow can we virtualize memory with pages, so as to avoid the prob-lems of segmentation? What are the basic techniques? How do we makethose techniques work well, with minimal space and time overheads?

3 A Simple Example And OverviewTo help make this approach more clear, let s illustrate it with asimpleexample. Figure (page 2) presents an example of a tiny address space,only 64 bytes total in size, with four 16-byte pages (virtual pages 0, 1, 2,and 3). Real address spaces are much bigger, of course, commonly 32 bitsand thus 4-GB of address space, or even 64 bits1; in the book, we ll oftenuse tiny examples to make them easier to 64-bit address space is hard to imagine, it is so amazingly analogy mighthelp: if you think of a 32-bit address space as the size of a tennis court,a 64-bit address spaceis about the size of Europe(!)

4 12 PAGING: INTRODUCTION644832160(page 3)(page 2)(page 1)(page 0 of the address space)Figure :A Simple 64-byte Address SpacePhysical memory, as shown in Figure , also consists of a numberof fixed-sized slots, in this case eight page frames (making for a128-bytephysical memory, also ridiculously small). As you can see in thediagram,the pages of the virtual address space have been placed at different loca-tions throughout physical memory; the diagram also shows the OS usingsome of physical memory for , as we will see, has a number of advantages over our previousapproaches.

5 Probably the most important improvement will beflexibil-ity: with a fully-developed paging approach, the system will be able tosupport the abstraction of an address space effectively, regardless of howa process uses the address space; we won t, for example, make assump-tions about the direction the heap and stack grow and how they are frame 7page frame 6page frame 5page frame 4page frame 3page frame 2page frame 1page frame 0 of physical memoryreserved for OS(unused)page 3 of ASpage 0 of AS(unused)page 2 of AS(unused)page 1 of ASFigure :A 64-Byte Address Space In A 128-Byte Physical MemoryOPERATINGSYSTEMS[ ] : INTRODUCTION3 Another advantage is thesimplicityof free-space management that pag-ing affords.

6 For example, when the OS wishes to place our tiny 64-byteaddress space into our eight-page physical memory, it simply finds fourfree pages; perhaps the OS keeps afree listof all free pages for this, andjust grabs the first four free pages off of this list. In the example, the OShas placed virtual page 0 of the address space (AS) in physical frame 3,virtual page 1 of the AS in physical frame 7, page 2 in frame 5, and page3 in frame 2. Page frames 1, 4, and 6 are currently record where each virtual page of the address space is placedinphysical memory, the operating system usually keeps aper-processdatastructure known as apage table.

7 The major role of the page table is tostoreaddress translationsfor each of the virtual pages of the addressspace, thus letting us know where in physical memory each page our simple example (Figure , page 2), the page table would thushave the following four entries: (Virtual Page 0 Physical Frame 3),(VP 1 PF 7), (VP 2 PF 5), and (VP 3 PF 2).It is important to remember that this page table is aper-processdatastructure (most page table structures we discuss are per-process struc-tures; an exception we ll touch on is theinverted page table). If anotherprocess were to run in our example above, the OS would have to managea different page table for it, as its virtual pages obviously maptodifferentphysical pages (modulo any sharing going on).

8 Now, we know enough to perform an address-translation s imagine the process with that tiny address space (64 bytes) is per-forming a memory access:movl <virtual address>, %eaxSpecifically, let s pay attention to the explicit load of the data fromaddress<virtual address>into the registereax(and thus ignore theinstruction fetch that must have happened prior).Totranslatethis virtual address that the process generated, we haveto first split it into two components: thevirtual page number (VPN), andtheoffsetwithin the page. For this example, because the virtual addressspace of the process is 64 bytes, we need 6 bits total for our virtualaddress(26= 64).

9 Thus, our virtual address can be conceptualized as follows:Va5Va4Va3Va2Va1Va0In this diagram, Va5 is the highest-order bit of the virtual address, andVa0 the lowest-order bit. Because we know the page size (16 bytes), wecan further divide the virtual address as follows:Va5Va4Va3Va2Va1Va0 VPNoffsetc 2008 19, ARPACI-DUSSEAUTHREEEASYPIECES4 PAGING: INTRODUCTIONThe page size is 16 bytes in a 64-byte address space; thus we need tobe able to select 4 pages, and the top 2 bits of the address do , we have a 2-bit virtual page number (VPN). The remaining bits tellus which byte of the page we are interested in, 4 bits in this case; we callthis the a process generates a virtual address, the OS and hardwaremust combine to translate it into a meaningful physical address.

10 For ex-ample, let us assume the load above was to virtual address 21:movl 21, %eaxTurning 21 into binary form, we get 010101 , and thus we canex-amine this virtual address and see how it breaks down into a virtual pagenumber (VPN) and offset:010101 VPNoffsetThus, the virtual address 21 is on the 5th ( 0101 th) byte of virtualpage 01 (or 1). With our virtual page number, we can now index ourpage table and find which physical frame virtual page 1 resides within. Inthe page table above thephysical frame number(PFN) (also sometimescalled thephysical page numberorPPN) is 7 (binary 111).