a new page table for 64-bit address spaces m. talluri, m. d. hill, y. a. kalidi university of...
TRANSCRIPT
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 but
very 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:
Virtual Address
Physical Address
MASTER INDEX
Offset
Offset
1ary 2ary
SUBINDEX
< Page Number >
Frame No
FrameAddr.
(unchanged)
CURRENT ORGANIZATIONS (III)
– Hashed (inverted) page tables:
VPN hashVPN
PPN
VPN = virtual page numberPPN = “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.
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
VPN hashVPN
PPN0
PPN1
Handling partial subblocking • Since all page frames are contiguous, have a single PPN per cluster
• Bitmap (bm) indicateswhich pages are in memory
VPN hashVPN0
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 a single 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