Virtual memory is the hardware-software mechanism that gives every process the illusion of a private, contiguous address space spanning terabytes — even though physical RAM is shared, fragmented, and far smaller — by translating virtual addresses to physical addresses through page tables managed by the OS and enforced by the MMU (memory management unit) in hardware. Virtual memory enables process isolation (one process cannot access another's data), overcommitment (allocate more memory than physically exists), memory-mapped files, and demand paging (load only what's needed). Every modern processor — from phone SoCs to AI servers — implements virtual memory.
How it works — address translation. When a program accesses address 0x7FFF_1234_5678, the MMU splits it into a page number + offset, walks the multi-level page table (4 or 5 levels on x86-64), and produces the physical address. If the page is not in RAM (page fault), the OS loads it from storage (swap or file). This happens on every memory access — so it must be fast:
The Translation Lookaside Buffer (TLB) caches recent translations so >99% of accesses resolve in 1 cycle without walking the page table.
Page table structure (x86-64, 4-level):
| Level | Bits used | Entries | Each entry covers | Name |
|---|---|---|---|---|
| PML4 (L4) | [47:39] | 512 | 512 GB | Page map level 4 |
| PDPT (L3) | [38:30] | 512 | 1 GB | Page directory pointer |
| PD (L2) | [29:21] | 512 | 2 MB | Page directory |
| PT (L1) | [20:12] | 512 | 4 KB | Page table |
| Offset | [11:0] | — | 1 byte (within 4 KB page) | — |
Total addressable: 2⁴⁸ bytes = 256 TB of virtual space per process (5-level paging extends to 2⁵⁷ = 128 PB).
TLB — the critical performance structure. A full page-table walk takes 4 memory accesses (one per level) × ~5 ns each = 20 ns penalty. The TLB caches 64–4096 recent translations in a small, fast associative array:
| TLB type | Entries | Page size | Hit rate | Miss penalty |
|---|---|---|---|---|
| L1 ITLB | 64–128 | 4 KB | >99% | ~7 cycles (L2 TLB) |
| L1 DTLB | 64–96 | 4 KB | >99% | ~7 cycles |
| L2 STLB (unified) | 1024–4096 | 4 KB / 2 MB | >99.9% | ~20 ns (page walk) |
| Huge-page TLB | 32–64 | 2 MB or 1 GB | ~100% (AI workloads) | — |
Huge pages — why AI workloads need them. A 80 GB HBM allocation at 4 KB pages requires 20 million page-table entries and 20 million TLB slots (impossible — TLBs are small). At 2 MB huge pages: only ~40,000 entries. At 1 GB pages: only 80 entries — fits entirely in the TLB with zero misses. This is why AI frameworks (PyTorch, JAX) and GPU drivers use huge pages for pinned memory: eliminating TLB misses on the massive tensor allocations that dominate AI workloads.
Virtual memory for GPU and AI chips:
- CPU MMU: full virtual memory — page tables in DRAM, hardware page-table walker, 4-level or 5-level, demand paging, copy-on-write.
- GPU (NVIDIA): separate GPU page tables managed by the driver. Unified Virtual Memory (UVM) allows CPU and GPU to share a virtual address space — the driver migrates pages between CPU DRAM and GPU HBM on demand (but at high cost; explicit placement is preferred for performance).
- AI ASIC (TPU): minimal or no virtual memory — DMA addresses are physical or use a simple IOMMU. The software runtime manages all allocation explicitly.
Page faults and demand paging. When a virtual page has no physical mapping (first access, swapped out, or memory-mapped file), a page fault triggers: 1. CPU traps to the OS kernel 2. OS determines the cause (valid fault → allocate page; invalid → segfault/kill) 3. OS finds a free physical frame (or evicts one to swap) 4. OS fills the page (zeroed, from file, from swap) 5. OS updates the page table, returns to user — process resumes
A page fault takes ~1–10 microseconds — acceptable for rare events, catastrophic if frequent (thrashing). AI training avoids this by pinning all memory upfront.
<svg viewBox="0 0 760 470" xmlns="http://www.w3.org/2000/svg" font-family="-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,sans-serif">
<rect x="0" y="0" width="760" height="470" fill="#0d1117"/>
<text x="380" y="28" fill="#e6edf3" font-size="21" font-weight="700" text-anchor="middle">Virtual Memory Technical Microarchitecture</text>
<text x="380" y="48" fill="#8b98a5" font-size="12" text-anchor="middle">Detailed Domain Pipeline, Architectural Blocks & Engineering Performance Optimization (ID 100197)</text>
<!-- CPU PIPELINE (3 Column Panels) -->
<g transform="translate(25, 75)">
<rect width="220" height="325" fill="#161b22" stroke="#30363d" stroke-width="1.5" rx="8"/>
<text x="110" y="25" fill="#60a5fa" font-size="12" font-weight="700" text-anchor="middle">1. Fetch & Decode</text>
<rect x="15" y="45" width="190" height="65" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="105" y="70" fill="#93c5fd" font-size="11" font-weight="700" text-anchor="middle">Instruction Fetch (IF)</text>
<text x="105" y="90" fill="#8b98a5" font-size="9" text-anchor="middle">PC Generator & L1 I-Cache</text>
<rect x="15" y="125" width="190" height="65" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="105" y="150" fill="#93c5fd" font-size="11" font-weight="700" text-anchor="middle">Branch Predictor</text>
<text x="105" y="170" fill="#8b98a5" font-size="9" text-anchor="middle">Gshare / TAGE & BTB</text>
<rect x="15" y="205" width="190" height="95" fill="#0d1117" stroke="#1d4ed8" rx="4"/>
<text x="105" y="230" fill="#e6edf3" font-size="11" font-weight="700" text-anchor="middle">Instruction Decode (ID)</text>
<text x="105" y="250" fill="#8b98a5" font-size="9" text-anchor="middle">Register Rename & ROB</text>
<text x="105" y="275" fill="#3fb950" font-size="9" font-weight="700" text-anchor="middle">Width: 4-Way Superscalar</text>
</g>
<g transform="translate(270, 75)">
<rect width="220" height="325" fill="#161b22" stroke="#30363d" stroke-width="1.5" rx="8"/>
<text x="110" y="25" fill="#60a5fa" font-size="12" font-weight="700" text-anchor="middle">2. Execution Engine</text>
<rect x="15" y="45" width="190" height="75" fill="#0d1117" stroke="#60a5fa" stroke-width="1.5" rx="4"/>
<text x="105" y="70" fill="#ffffff" font-size="11" font-weight="700" text-anchor="middle">ALU Cluster (INT)</text>
<text x="105" y="95" fill="#93c5fd" font-size="9" text-anchor="middle">Single-Cycle Arithmetic & Shifts</text>
<rect x="15" y="135" width="190" height="75" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="105" y="160" fill="#d2a8ff" font-size="11" font-weight="700" text-anchor="middle">FPU / SIMD Engine</text>
<text x="105" y="185" fill="#8b98a5" font-size="9" text-anchor="middle">256-bit Vector FMA Pipelines</text>
<rect x="15" y="225" width="190" height="75" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="105" y="250" fill="#fbbf24" font-size="11" font-weight="700" text-anchor="middle">Load / Store Queues</text>
<text x="105" y="275" fill="#8b98a5" font-size="9" text-anchor="middle">Out-of-Order Memory Disambiguation</text>
</g>
<g transform="translate(515, 75)">
<rect width="220" height="325" fill="#161b22" stroke="#30363d" stroke-width="1.5" rx="8"/>
<text x="110" y="25" fill="#60a5fa" font-size="12" font-weight="700" text-anchor="middle">3. Memory & Writeback</text>
<rect x="15" y="45" width="190" height="85" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="105" y="70" fill="#58a6ff" font-size="11" font-weight="700" text-anchor="middle">L1 D-Cache & TLB</text>
<text x="105" y="90" fill="#8b98a5" font-size="9" text-anchor="middle">32KB 8-Way Set Assoc</text>
<text x="105" y="110" fill="#3fb950" font-size="9" font-weight="700" text-anchor="middle">Hit Latency: 4 Cycles</text>
<rect x="15" y="145" width="190" height="85" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="105" y="170" fill="#58a6ff" font-size="11" font-weight="700" text-anchor="middle">L2 / L3 Cache Controller</text>
<text x="105" y="190" fill="#8b98a5" font-size="9" text-anchor="middle">Inclusive/Non-Inclusive Hierarchy</text>
<text x="105" y="210" fill="#3fb950" font-size="9" font-weight="700" text-anchor="middle">MESI Coherence Protocol</text>
<rect x="15" y="245" width="190" height="55" fill="#0d1117" stroke="#1d4ed8" rx="4"/>
<text x="105" y="270" fill="#e6edf3" font-size="11" font-weight="700" text-anchor="middle">In-Order Retirement</text>
<text x="105" y="288" fill="#8b98a5" font-size="8" text-anchor="middle">Commits Architectural State</text>
</g>
<!-- Key insight bar -->
<rect x="25" y="415" width="710" height="22" rx="3" fill="#0b1220" stroke="#233043" stroke-width="0.8"/>
<text x="380" y="430" fill="#fbbf24" font-size="9" font-weight="700" text-anchor="middle">Key Insight: Optimal Virtual Memory architecture balances performance throughput, systemic latency, and physical constraints.</text>
<text x="380" y="460" fill="#6b7684" font-size="11" text-anchor="middle">Technical specification & verification reference for Virtual Memory (Row ID 100197)</text>
</svg>
Virtual memory and the CFS platform. Virtual memory is the OS abstraction that lets multiple processes share hardware safely. The CFS operating-system keyword covers the broader OS context; the memory-hierarchy keyword covers the physical storage layers that VM maps onto; and the cache-coherence keyword covers how multiple cores agree on the contents of shared physical addresses that VM translates to.
Explore 500+ Semiconductor & AI Topics
From EUV lithography to CUDA optimization — search the full knowledge base or chat with our AI assistant.