Paging

Memory Partitioning Troubles Fragmentation Need for compaction/swapping A process size is limited by the available physical memory Dynamic growth of partition is troublesome No winning policy on allocation/deallocation P2 P3

The Basic Problem A process needs a contiguous partition(s) But Contiguity is difficult to manage Contiguity mandates the use of physical memory addressing (so far)

The Basic Solution Give illusion of a contiguous address space The actual allocation need not be contiguous Use a Memory Management Unit (MMU) to translate from the illusion to reality

A solution: Virtual Addresses Use n-bit to represent virtual or logical addresses A process perceives an address space extending from address 0 to 2 n -1 MMU translates from virtual addresses to real ones Processes no longer see real or physical addresses

Paged Memory Subdivide the address space (both virtual and physical) to “pages” of equal size Use MMU to map from virtual pages to physical ones Physical pages are called frames

Paging: Example 00 Virtual Physical Process 0 Process 1

Key Facts Virtual address spaces of different processes are independent –Two or more may have the same address range –Yet the mappings differentiate between them A virtual page has no storage of its own –It must be backed by a physical frame (real page) that provides the actual storage –A contiguous virtual space need not be physically contiguous

Key Facts Physical address space is independent of virtual address spaces –They can have different sizes –Allows process size to be independent of available physical memory size Page size is always a power of 2, to simplify hardware addressing

Page Tables 0 Virtual Page Table

Page Table Structure Indexed by virtual page number Contains frame number (if any) Contains protection bits Contains reference bit Frame No.vwrxf vwrxf vwrxf v: valid bit w: write bit r: read bit x: execute bit (rare) f: reference bit m: modified bit m m m

Mapping Virtual to Real Addresses Virtual address n bits virtual page numberoffset index into page table frame no.offset Physical address p bits s bits s: log (page size)

Example: PDP-11 Virtual address 16 bits vpnoffset frame no.offset Physical address 22 bits 13 bits Page size: 8K Up to 4M mem 8-entry page table (in hardware)

Weird Stuff: Free Page Management Virtual Physical Process 0Process 1 Key fact: A memory frame cannot be accessed unless mapped Free space

Fun Stuff: Sharing 00 Virtual Physical Process 0 Process 1

Sharing Processes can share pages by mapping their virtual pages to the same memory frame In UNIX and Windows, code segments of processes running the same program to share the pages containing executables –saves a lot of memory –saves loading time for frequently run programs Fine tuning using protection bits (rwx)

Fork Revisited: Copy-on-Write Virtual Physical FatherChild W W W W W W

Copy-on-Write Fork Initially no memory copying –Efficient –If an exec follows, no much harm Page tables set the protection to disallow writes If either father or child attempts to write, a page fault occurs

Copy-on-Write Virtual Physical FatherChild W W W W W W

Requirements for Sharing Page frames must have a reference count –Cannot be deallocated unless unmapped –Adds complexity to memory manager Protection bits must be set properly

Page Table Implementation

Page Table Implementations Key issues: Each instruction requires one or more memory accesses: –Mapping must be done very quickly Where do we store the page table? –It is now part of the context, with implications on context switching Hardware must support auxiliary bits

PDP-11 Example Revisited Page table is small (8 entries) –Can be implemented in hardware –Moderate effect on context switching time Each process will need an 8-entry array in its PCB to store page table when not running Protections works fine But: what if address space is 32-bit

Page Table Size Problems Assume 16K page size and 32-bit address space Then: For each process, there are 2 19 virtual pages Page table size: 2 19 * 4 bytes/entry –Page table requires 2 Mbytes –Cannot be stored in hardware, slowing down the mapping from virtual to physical addressing

Solution1: Multi-Level Page Tables Use two or three levels page tables All entries in the topmost level must be there Entries in lower levels are there only if needed Store page tables in memory Have one CPU register contain address of top-most level table

Example: SPARC Context table (up to 4K registers) 3-level page table offsetindex 1index 2index 3 Context Level 1 Level 2 Page Level 3

SPARC: Cont’d Only level 1 table need be there entirely –256 entries * 4 bytes/entry = 1K /process Context switching is not affected –Just save and restore the context register/process Second and third level tables are there only if necessary

Translation Lookaside Buffer A small associative memory in processor Contains recent mapping results Typically 8 to 32 entries If access is localized, works very well Must be flushed on context switching If TLB misses, then must resolve through page tables in main memory (slow)

Other Varieties 2-level page table in VAX systems 4-level page table in the 68030/68040 Organize the cache memory by virtual addresses (instead of physical addresses) –Remove the TLB from critical path –Combine cache misses with address translations –e.g. MIPS 3000/4000

Solution 2: Inverted Page Tables Rationale: Conventional per-process page tables depend on virtual memory size Virtual address space is getting larger (e.g. 64 bits) Size of physical memory projected is less than virtual memory in foreseeable future

Inverted Page Table Main Idea: Global page table indexed by frame number Each entry contains virtual address & pid Use TLB to reduce the need to access PT On a TLB miss: –Search page table for the –Physical address is obtained from the index of the entry (frame number)

Inverted Page Table Structure Indexed by frame number Entry contains virtual address and pid using the frame number (if any) Contains protection & reference Virtual addrvwrxf vwrxf vwrxf v: valid bit w: write bit r: read bit x: execute bit (rare) f: reference bit m: modified bit m m m Virtual addr pid

Mapping Virtual to Real Addresses Virtual address n bits virtual page numberoffset + pid: search key into inverted page table frame no.offset Physical address p bits s bits

Properties & Problems Table size is independent of virtual address size, only function of physical memory size TLB misses are expensive –We don’t know where to look –May require searching entire table (very bad) Virtual memory more expensive Sharing becomes very difficult

A Solution Organize Inverted Page Table as a hash table –Search key –Search in hardware or software Examples: IBM 38, RS/6000, HP PA-RISC systems

Sharing & Inverted Page Tables Conceivably possible with a general hashing function Requires an additional field in page table entry Virtual addrvwrxf vwrxf vwrxf m m m pid Frame no. Size no longer limited, so no system implements it