Paging
Paging Basics
- divide a process's virtual memory into fixed sized pages (typically 4KB)
- divide the physical memory into page sized chunks
- each chunk of physical memory is called frame or physical page
- only load pages in use into the frames, dynamically load pages as needed
Address Translation With Paging
- base & bound: process's virtual memory is contiguously mapped in physical memory, only needs 1 translation
- paging: must perform page level translations!
- page number needs to be translated, offest within a page is the same within a physical page
- 4096 = 2^12 bits, the lower 12 bits of a virtual address is an offset into a page and the higher bits are the page #
- page table
- an array that's indexed by page number and holds the page's corresponding frame number
- per process data structure managed by the kernel
- who should perform the memory translation?
- a frequent operation => hardware walks the page table
- how does the hardwware know where the page table is located?
- page table base register (
%cr3
) holds the address of the first level page table
- should this be a virtual or physical address?
- kernel is responsible for loading the process's page table into
%cr3
upon a context switch
- the cost of page table walk
- in the base & bound world, translation = add to base register, only takes several cycles
- with paging, each translation is itself an access to memory (~200 cycles)
- spatial locality, wouldn't want to keep looking up the same translation
- cache the result of memory translations: Translation Lookaside Buffer (TLB)
- TLB
- upon a memory access, hardware checks the TLB and starts the page table walk in parallel
- if there's a TLB hit, translation is done
- if not, waits for the page table walk to finish and caches the result to TLB
Costs of Page Tables
- how much space is taken up by a single page table?
- # of entries = size of virtual address space / page size
- page table has an entry for each page (very large array)
- what if a process only use a couple pages of its virtual memory?
- how to use less space for page table?
- large/super pages: make pages larger
- hardware support for 2MB (512 4K pages) and 1GB (262144 4K pages) pages
- same virtual address space, larger pages => fewer pages => smaller page tables
- also good for performance (less translations needed)
- any problem with larger page size?
- still need a page table for every process
- inverted page table
- instead of maintaining per process page tables, maintain a single global table that's indexed by frame number
- index = frame number, entry = pid + page number
- # of entries = size of physical memory / page size
- how would we perform a look up given a virtual address (page number)?
- search through each entry until we find a matching pid + page number
- if no matching entry, page fault
- slow look up! how can we improve this?
- use a hash function to hash pid + page number to a particular frame
- how to handle hash collision?
- what's the cost of computing hash on each access?
- multilevel page table
- per-process page table but with indirections (not all page table entries are allocated at once)
- with a single array, all entries must be allocated at once, but what if we use hierarchical arrays?
- indirection can help space saving when the entries (pages) are sparse and adjacent
- does this always result in less memory used?