An Operating Systems Vade Mecum

86 Space Management Chapter 31 const2 BitsPerVirtualAddress = 18; { for example }3 BitsPerPhysicalAddress = 24; { for example }4 BitsPerVirtualPageAddress = 8; { for example }5 BitsPerOffsetAddress =6 BitsPerVirtualAddress − BitsPerVirtualPageAddress;7 PageSize = 2 BitsPerOffsetAddress ;8 NumberOfPageFrames = 2 BitsPerPhysicalAddress / PageSize;9 { maximum allowed by the hardware; we may have fewer }10 PageLimit = 2 BitsPerVirtualAddress / PageSize;11 { number of pages per virtual space }12 type13 PageFrame = array 0 : PageSize − 1 of byte;14 PageFrameNumber = 0 .. NumberOfPageFrames − 1;15 PhysicalStore = array PageFrameNumber of PageFrame;If we use the constants suggested in lines 2−4, virtual addresses are 18 bits long. Virtualspace is therefore limited to 256K bytes. A process may have a virtual space ranginganywhere between 0 bytes and this limit in increments of one page size. A virtual pageaddress is 8 bits. The 256K bytes of virtual store are therefore divided into 256 pages,each having 1K bytes. The number of bits in an offset is 18 − 8 = 10, which fits this pagesize. The largest virtual space has 256K / 1K = 256 pages. A physical address isdescribed by 24 bits. As a result, the largest amount of physical store that may be placedon the machine is 16M bytes. A particular machine may have less store. Physical storecan have as many as 16M / 1K = 16K page frames. On this particular machine, physicalspace is much larger than any virtual space. This situation is found, for example, onsome 16-bit computers like the DEC PDP-11. More typically, virtual spaces are allowedto be larger than the amount of physical store present.Pages fit exactly into page frames in physical store, so there is no external waste.However, internal waste is likely because a program might not need a virtual store whoselength is exactly divisible by the page size. On the average, each process will waste onehalf of the last page. The choice of page size, which is a policy bound at the time theoperating system is designed, involves a tradeoff among various considerations:(1) overhead space — least with large pages, since page tables have fewer entries.(2) internal waste — smallest with small pages, since one-half of a small page issmall. Figure 3.12 shows the contrast between small and large pages for thesame virtual space. When pages are small, there is less internal waste, but thepage table is longer.(3) cold-start faults — lower with large pages. These are the faults needed to bringthe program into main store the first time. With larger pages, there are fewertotal pages, hence fewer cold-start faults.(4) page-fault rate — generally lower with small pages, assuming that a fixed amountof main store is available. Regions of heavy use within a virtual space tend to berelatively small, and the computer can fit more such regions into a fixed-sizemain store if page size is small.(5) efficiency of transfer between main and backing store — best with large pages,since they take about the same amount of time as small pages to transfer. Thetotal transfer time is dominated by disk rotational and seek latency, not transferlatency. (We discuss disk transfers in Chapter 5.)