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?