Paging: Smaller Tables

1. Paging: Smaller Tables Youngju Song(youngju.song@sf.snu.ac.kr) Jeongyoon Eo(jyeo@rubis.snu.ac.kr) School of Computer Science and Engineering Seoul National University

2. Problem • Page tables consume TOO MUCH MEMORY 32bit address space 4KB page size 1M entries 4B entry size page table size = 4B * 1M = 4MB page tables consume 4MB * # processes … n processes

3. Bigger Pages 32bit address space 16KB page size 4B entry size 256K entries 1/4x entries page table size = 4B * 256K = 1MB • Bigger page size yields smaller page table size • Problem: Internal fragmentation • Pages are under-utilized • Bigger page size means fewer # of pages: memory runs out quickly

4. Hybrid Approach: Paging and Segmentation code segment base reg stack segment heap segment bound reg Total 3 page tables per process • Getting the best of both paging AND segmentation • 1 page table per segment, each with base and bound register • base register: physical address of the segment’s page table • bound register: # of maximum valid page in the segment • Example: 32bit address space, 4KB page, code, stack, heap segment

5. Hybrid Approach: Paging and Segmentation SN = (VirtualAddress & SEG_MASK) >> SN_SHIFT VPN = (VirtualAddress & VPN_MASK) >> VPN_SHIFT AddressOfPTE = Base[SN] + (VPN * sizeof(PTE)) SN VPN offset 12 31 30 0 4 102 code segment page table Unused 002 Code segment 102 Stack segment 012 Heap segment 112 base reg Base[102] VPN * sizeof(PTE) PFN offset bound reg Example: 32bit address space, 4KB page, code, stack, heap segment TLB miss handling in the code segment, VPN=0x4

6. Hybrid Approach: Paging and Segmentation • Page table consists of only allocated pages’ entries • Much smaller page table size • Problem • Using segmentation is NOT flexible: • Assumes certain usage pattern of address space • For other usage patterns, page table size might not be small • ex) Large but sparsely used heap • External fragmentation: • Memory is managed in page-size • Page tables now can be of arbitrary size (in multiples of PTEs) • Finding free space for page table: complicated

8. 8

9. Multi-Level Page Tables • Paging page table itself! • Chop up the page table into page-sized units • Page directory tracks chopped units

10. Multi-Level Page Tables –Page Directory Entries(PDE) • valid bit of PDE • invalid: entire page of page table contain no valid page • valid: at least one PTE on that page pointed to by this PDE is valid • Page Frame Number (PFN) • page frame number != physical frame number!

11. Multi-Level Page Tables

12. Multi-Level Page Tables – Pros • Allocates page table space proportional to address space • Compact, supports sparse address space • Easier to manage memory • Getting next free page is easy • Level of indirection

13. Multi-Level Page Tables – Cons • Time-space trade-off • Smaller page table size • TLB miss => two loads from memory • Increased complexity

14. Multi-Level Page Tables –Implementation Detail PDEAddr = PageDirBase + (PDIndex * sizeof(PDE)) Get PDEfrom PDEAddr(memory load) PTEAddr = (PDE.PFN << SHIFT) + (PTIndex * sizeof(PTE)) GetPTE from PTEAddr (memory load) ...+ TLB

15. Multi-Level Page Tabels – More Than Two Levels • Page directory itself is too big! • Smaller page, 64bit address space • Apply exactly same technique again • Linux supports various multi-level page tables of different architectures • ex) 3-level for x86-64

16. Inverted Page Tables Mapped Physical Memory Inverted Page Table Hash Anchor Table Collision Chain for Multiple VPNs : PFN mapping Hash Function HEAD PTE Content • 1 page table per system, 1 PTE for every physical page • Added level of indirection: HAT(Hash Anchor Table) • Tradeoff: Smaller page table size, increased # of accesses per lookup • Increased # of access per lookup requires fastlookup: uses hashing

17. Summary • Solutions for TOO BIG page tables • Bigger pages • Hybrid of paging and segmentation • Multi-level page tables • Inverted page tables