A NEW PAGE TABLE FOR 64-BIT ADDRESS SPACES M. Talluri, M. D. Hill, Y. A. Kalidi University of Wisconsin, Madison Sun Microsystems Laboratories
THE PROBLEM • Programs’ memory usage doubles every one or two years. • Most processor architectures are now moving from 32-bit to 64-bit virtual address spaces • How would current page table organizations scale up? • Will support very large butvery sparsely populated address spaces
CURRENT ORGANIZATIONS (I) • Three main approaches: • Linear page tables: • PTs are too large to be stored in main memory • Store PT in virtual memory (VMS solution) • Very large page tables need more than 2 levels (3 levels on MIPS R3000)
CURRENT ORGANIZATIONS (II) • Forward-mapped page tables: < Page Number > 1ary 2ary Offset Virtual Address MASTER INDEX SUBINDEX (unchanged) Frame Addr. Offset Frame No Physical Address
hash VPN VPN PPN CURRENT ORGANIZATIONS (III) • Hashed (inverted) page tables: VPN = virtual page number PPN = “physical page” number = page frame number
What is wrong with them? • None of these solutions scales up to 64-bit addresses: • Linear and forward-mapped page tables require too many levels • Hashed page tables require too much space: • Must store the VPN and the next pointer in addition to PPN
CLUSTERED PAGE TABLES • Variant of hashed page tables • Each entry stores mapping information for a cluster of consecutive page table entries • Number of pages in a cluster is called the clustering factor.
How they work hash VPN VPN PPN0 PPN1 Clustering factor = 2 Each entry maps 2 contiguous VPNs
Advantages of clustered PTs • Require much less space overhead: only one VPN and one next pointer per cluster • Take advantage of the fact that the address space of many programs consists of small clusters of pages • Interact much better with the TLB miss handling firmware or software.
Are we really saving space? • Assume a clustering factor of 2 • Each entry maps 2 pages and occupies 4×8 bytes VPN PPN0 PPN1
The answer • Without clustering, each entry maps one page and occupies 3×8 bytes • Clustering will save space if more than 67% of the page mappings are useful VPN PPN
HANDLING TLB MISSES • Page table organization should allow efficient handling of TLB misses by • firmware (classical solution) • software (MIPS, Alpha, UltraSPARC) • Should handle two recent TLB advances • subblocking • superpages
Subblocking • Associates multiple physical page numbers (PPN’s) with each TLB tag: • Complete subblocking allows the page frames containing the subblock pages to be anywhere in main memory (MIPS 4X00x) • Partial subblocking requires these page frames to be placed in a single, aligned block of main memory; there is one PPN per TLB tag.
Handling complete subblocking • Have cluster size of PT equal to subblocking factor hash VPN VPN PPN0 PPN1
Handling partial subblocking • Since all page frames are contiguous, have a single PPN per cluster • Bitmap (bm) indicateswhich pages are in memory hash VPN VPN0 PPN0 bm
Note • Each page table entry maps two virtual pages into two physical pages • Virtual page VPN0 is mapped into physical page PPN0 • Virtual page VPN0 + 1 is mapped into physical page PPN0 + 1 • These mappings are valid if the virtual page is actually in main memory
Problem • A virtual memory system has 64-bit addresses and a clustered page table with a clustering factor of 4. If each address occupies 8 bytes, what would be the length of a page table entry for: (a) partial subblocking ? (b) complete subblocking ?
Hint • No additional space is required for bitmap • If page size is equal to 2p,page size will occupy 64 -p bits • In practice, page size > 1,024 and p > 10 • Can use these p bits to store the bitmap
Solution (I) • With complete subblocking, each PTE has: • one virtual page number • four physical page numbers • one pointer to next entry • 6 entries × 8 bytes = 48 bytes
Solution (II) • With partial subblocking, each PTE has: • one virtual page number • one physical page number • four bits of bitmap • one pointer to next entry • 3 entries × 8 bytes = 24 bytes
Superpages • Sets of pages that are aligned both in virtual and in physical memory • Brought in memory and out of memory as asingle entity • Size is a power-of-two multiple of the page size (MIPS, UltraSPARC, Alpha, PowerPC) • Large superpages (256KB and above) are especially useful for kernel data
Handling superpages (I) • We can: • Have one PTE for each page in the superpage Simplest solution but does not save space • Have one page table per superpage size (including isolated pages) Each page miss will now have to search several PTs
Handling superpages (II) • Store superpage mappings at the appropriate level of a PT Only works with multi-level PTs having a tree structure • Pick hash function such that all pages that are in the same superpage are in the same bucket Results in larger buckets and longer searches
Handling superpages (III) • Best solution seems to be • Use same data structures for small superpages and partial subblocks • Otherwise have one entry for each cluster in the superpage • Support very large superpages on an ad hoc basis There will be very few of them
CONCLUSIONS • 64-bit addresses will force a rethinking of page table organization • New organizations must support efficient handling of TLB misses • Supporting partial subblocking is most important issue because partial subblocking requires simpler OS support than superpages and reduces more effectively page table sizes