Part 7: Virtual Memory: Multi-Level Paging, Page Faults & TLB Translation

1. Architectural Motivations for Virtual Memory

• Process Protection & Security: Each process operates in its own isolated address space. Process A cannot read or write Process B's memory. Hardware protection bits enforce read, write, and execute permissions (preventing code injection via the Non-Execute / NX bit).
• Transparent Memory Extension: Secondary disk storage acts as an overflow extension for physical RAM. Programs can exceed total installed physical DRAM capacity.
• Simplified Relocation & Compaction: Code is compiled to standard fixed virtual addresses without knowing where in physical DRAM the OS will load it.

2. Paging Architecture: Virtual to Physical Translation

Virtual memory divides address spaces into fixed-size contiguous blocks termed Pages (standardized at 4 KB = $4096\text{ bytes}$). Physical memory is similarly divided into identical-sized blocks called Page Frames.

A Virtual Address is partitioned into two components:

Because pages are 4 KB ($2^{12}$ bytes), the lower 12 bits represent the byte offset within the page and remain identical between virtual and physical addresses. The MMU looks up the VPN in a Page Table to retrieve the corresponding Physical Frame Number (PFN).

3. Multi-Level Page Tables in 64-Bit Architectures

In a 64-bit architecture with a 48-bit virtual address space, a single flat page table would require $2^{36}$ page table entries (PTEs). At 8 bytes per entry, a flat table would demand an absurd 512 Gigabytes of RAM per process just to hold the table itself!

Modern architectures (such as x86-64 and ARMv8/v9) solve this via 4-Level Hierarchical Paging (or 5-level paging for 57-bit addresses):

Because intermediate page tables are allocated dynamically on-demand, unmapped sparse virtual regions consume zero memory, slashing page table overhead from 512 GB down to a few kilobytes for typical applications.

4. Translation Lookaside Buffer (TLB) Acceleration

Walking a 4-level page table requires four consecutive DRAM memory reads (costing ~200 ns) before the CPU can fetch a single instruction or variable—a catastrophic 5x slowdown.

To eliminate page walk latency, the CPU incorporates a small, high-speed, fully-associative hardware cache called the Translation Lookaside Buffer (TLB):

• TLB Hit (>99% of accesses): The VPN-to-PFN translation is resolved in less than 1 clock cycle (<0.5 ns).
• TLB Miss: The MMU hardware page-table walker navigates the hierarchical tree in DRAM, resolves the physical address, and caches the mapping in the TLB for subsequent instructions.
• HugePages Optimization: Enterprise databases (PostgreSQL, MySQL) and hypervisors utilize 2 MB or 1 GB HugePages. A single 2 MB TLB entry covers 512x the address space of a 4 KB page, dramatically reducing TLB misses on massive in-memory datasets.