3.2 Translation Lookaside Buffer (TLB) & Multi-Level Page Tables

Back to DBMS Notes

📚03Topic 3.2⏱️15 min

🎯High-Yield For:Hardware TLB caches and multi-level page tables solve the two primary bottlenecks of virtual memory: memory translation latency (EMAT) and catastrophic page table memory bloat in 32-bit and 64-bit microprocessors.

💡 Core Intuition:

🍳 The Everyday Analogy:

Imagine an executive managing a multi-national conglomerate. Hundreds of calls arrive every hour asking to connect with specialized regional directors across 50 global branches.

If the executive had to stand up, walk down to the basement archives, and flip through a $500\text{-page}$ master phonebook for every single incoming call, the office would grind to a halt (The $2\times$ Memory Latency Penalty of basic paging).

Instead, the executive adopts a two-part operational strategy:

1. The Executive Desk Rolodex (The TLB): A small, high-speed rotary card index kept right on the desk. It holds the direct extension numbers of the $16$ most frequently contacted directors. For $98\%$ of calls, the executive glances at the desk, finds the number in 1 second, and transfers the call instantly (TLB Hit).
2. The Multi-Tier Filing Cabinet (Multi-Level Paging): For the rare call whose number is not on the desk (TLB Miss), the executive does not store a massive, continuous million-entry encyclopedia in the office. Instead, there is a Master Index Drawer (Level-1 Page Directory). Opening drawer Europe reveals a small folder containing only German directors (Level-2 Page Table). Unused regions (e.g., Antarctica) don't even have folders printed, saving massive filing space!

💻 Bridging to Computer Science:

In modern microprocessor architecture:

• The Translation Lookaside Buffer (TLB) is a specialized, ultra-fast associative hardware cache (Content Addressable Memory, or CAM) built directly into the processor's Memory Management Unit (MMU). It caches recent Virtual Page Number -> Physical Frame Number translations, reducing translation overhead from over $100\text{ ns}$ down to under $1\text{ ns}$.
• Multi-Level Page Tables solve the linear memory explosion problem. By organizing the page table into a hierarchical tree where each sub-table occupies exactly one physical page, unused virtual memory regions require zero physical memory allocations.

---

📑Table of Contents

• ⚡ The Memory Latency Crisis & TLB Hardware Architecture
  • The Solution: Translation Lookaside Buffer (TLB)
• 🔄 Hardware Translation Flow with TLB (Hit vs Miss Mechanics)
  • Key Distinction: TLB Miss vs Page Fault
• ⏱️ Effective Memory Access Time (EMAT) Mathematics with TLB
  • Case 1: Sequential TLB then RAM Access (Standard Model)
  • Case 2: Simultaneous (Parallel) TLB and Cache Search
  • Concrete Demonstration of TLB Acceleration:
• 🌲 The Multi-Level Paging Architecture (Hierarchical Paging)
  • The Core Architectural Principle: Page the Page Table!
  • The Sparsity Advantage:
• 📐 Mathematical Derivation of Multi-Level Address Splitting
  • 1. Two-Level Paging Bit-Splitting (Standard 32-Bit System)
  • 2. Multi-Level EMAT Formula (The Latency Trade-off)
• 🏭 Real-World Production Context:
  • 1. The x86-64 4-Level Paging Architecture (PML4)
  • 2. Multi-Core TLB Shootdowns & Process Context Identifiers (PCID)
• 📐 Numerical Applications & Worked Examples
  • Example 1: EMAT Derivations Across Single-Level vs Multi-Level Paging
  • Example 2: Determining Number of Paging Levels and Bit Allocation
  • Example 3: Memory Footprint: Flat Table vs Two-Level Page Table
• 🎯 Exam & Interview Pitfall Check

---

⚡ The Memory Latency Crisis & TLB Hardware Architecture

In basic single-level paging (established in Topic 3.1), every instruction requiring a memory operand forces the CPU to perform two sequential physical memory accesses:

1. Access 1: Read the Page Table Entry (PTE) from RAM at address $\text{PTBR} + p \times e$.
2. Access 2: Read the actual target data/instruction from RAM at address $(f, d)$.

If DRAM access time is $100\text{ ns}$, every memory operation takes $200\text{ ns}$. The processor experiences a $100\%$ performance degradation strictly due to virtual-to-physical address translation!

Architecture Flow

Sequential Latency Penalty of Basic Paging (Zero TLB)

Every memory reference forces two serialized round-trips to off-chip DRAM

⚡Step 1

CPU Instruction Request

Generates virtual address requiring address translation.

→

Virtual Address

🧠Access 1

Read PTE from DRAM

Reads page table entry at PTBR + p * e (100 ns latency).

→

Frame Number (f)

📦Access 2

Read Data from DRAM

Accesses target operand word at address (f, d) (Total: 200 ns).

The Solution: Translation Lookaside Buffer (TLB)

The Translation Lookaside Buffer (TLB) is an on-chip associative cache integrated directly inside the MMU. Because it is implemented using Content Addressable Memory (CAM), the hardware searches all cached page numbers simultaneously in parallel within a fraction of a clock cycle ($0.5\text{ to }1\text{ ns}$).

MMU Translation Lookaside Buffer (TLB) Architecture

On-chip CAM cache eliminating redundant main memory page table walks

L0 Hardware

Content Addressable Memory (CAM) Array

⚡

Parallel hardware comparators search all TLB tag entries simultaneously in < 1 ns.

Tag Field: Virtual Page Number (VPN)Data Field: Physical Frame Number (PFN)Capacity: Typically 64 to 1536 entries across split L1/L2 TLBsAssociativity: Fully Associative or 4-Way / 8-Way Set-Associative

↓Parallel Associative Tag Comparison

Status Flags

Hardware Protection & Coherence Attributes

🛡️

Per-entry control bits enforcing protection and multi-process safety.

Valid Bit (V): Indicates active mappingDirty Bit (D): Tracks memory modificationsAccess Rights (R/W/X): Enforces memory permissions directly on chipASID / PCID: Address Space / Process Context Identifier (prevents flushes on context switch)

---

🔄 Hardware Translation Flow with TLB (Hit vs Miss Mechanics)

When the CPU generates a virtual address with Page Number $p$ and Offset $d$, the MMU executes the following hardware pipeline:

Architecture Flow

Complete MMU Translation Cycle (TLB Hit vs Page Table Walk)

Hardware execution path distinguishing TLB hits, TLB misses, and Page Fault exceptions

📍Step 1

Virtual Address

CPU emits Logical Address; MMU extracts Page Number p and intra-page Offset d.

→

🔍Step 2

Parallel TLB Search

CAM array compares Page Number p against all TLB tags simultaneously in < 1 ns.

→

⚡Branch A

TLB Hit (Fast Path)

Frame Number f retrieved instantly from TLB. Form PA (f, d) -> Direct RAM access (1 access total).

→

🚶Branch B

TLB Miss (Walk)

MMU accesses DRAM at PTBR + (p * e) to fetch PTE -> Updates TLB with new mapping.

→

🚨Exception

Page Fault Check

If PTE Valid bit = 0 during page walk, hardware raises interrupt trap to OS (Page Fault).

Key Distinction: TLB Miss vs Page Fault

Students frequently confuse a TLB Miss with a Page Fault. They operate at completely different layers of the computing hierarchy:

[!IMPORTANT] Hierarchy Rule: A Page Fault always induces a TLB Miss (because if the page is not in RAM, its mapping cannot exist in the TLB). However, a TLB Miss rarely causes a Page Fault (over $99.9\%$ of TLB misses locate the PTE in RAM immediately).

---

⏱️ Effective Memory Access Time (EMAT) Mathematics with TLB

The quantitative performance metric evaluating virtual memory translation is Effective Memory Access Time (EMAT):

📐Effective Memory Access Time (EMAT) Formulasequation

Let:

• $c$ = TLB Hit Ratio ($0 \le c \le 1$, typically $0.95\text{ to }0.99$)
• $t$ = TLB Access Latency (typically $1\text{ to }2\text{ ns}$)
• $m$ = Main Memory (DRAM) Access Latency (typically $50\text{ to }100\text{ ns}$)

Case 1: Sequential TLB then RAM Access (Standard Model)

In standard hardware, the MMU checks the TLB first. On a hit, it accesses RAM once. On a miss, it accesses RAM twice (once for Page Table, once for data): $\text{EMAT} = c \times (t + m) + (1 - c) \times (t + 2m)$

Expanding and simplifying algebraically: $\text{EMAT} = t + c \cdot m + (1 - c) \cdot 2m = t + m(c + 2 - 2c)$ $\mathbf{\text{EMAT} = t + (2 - c)m}$

Case 2: Simultaneous (Parallel) TLB and Cache Search

In advanced pipelined processors where TLB tag comparison runs in parallel with cache indexing: $\mathbf{\text{EMAT} = c \times m + (1 - c) \times (t + 2m)}$

Concrete Demonstration of TLB Acceleration:

Assume $t = 2\text{ ns}$, $m = 100\text{ ns}$, and $c = 95\%$ ($0.95$):

• Without TLB: $\text{EMAT} = 2 \times m = 2 \times 100\text{ ns} = \mathbf{200\text{ ns}}$.
• With TLB: $\text{EMAT} = 2 + (2 - 0.95) \times 100 = 2 + (1.05 \times 100) = 2 + 105 = \mathbf{107\text{ ns}}$

The TLB achieves an instantaneous $46.5\%$ latency reduction, bringing effective memory speed within $7\%$ of bare-metal physical DRAM!

---

🌲 The Multi-Level Paging Architecture (Hierarchical Paging)

While the TLB solves the time latency crisis, it does nothing to solve the spatial memory bloat crisis of single-level flat page tables:

• As proven in Topic 3.1, a single-level page table for a 32-bit system with $4\text{ KB}$ pages requires $4\text{ MB}$ of contiguous memory per process.
• For a 64-bit system, a flat table requires an impossible $32\text{ Petabytes per process}$.

The Core Architectural Principle: Page the Page Table!

A running program uses only a fraction of its total address space (code at bottom, stack at top, heap in middle, vast empty space in between).

Instead of allocating one giant contiguous array for all $2^p$ entries, we partition the Page Table itself into $4\text{ KB}$ pages, creating a hierarchical tree of page tables:

Two-Level Hierarchical Paging Traversal

Hierarchical dereferencing dynamically isolating allocated address spaces

Level 1

Page Directory (Outer Table)

📁

Indexed by p1 bits. Always resident in physical DRAM (addressed by CR3/PTBR).

1024 Directory Entries in 32-bit systems (occupies exactly one 4 KB frame)Points to base physical address of target Inner Page TableIf entry is marked Invalid (V = 0), entire 4 MB region requires zero inner tables in RAM!

↓Directory Pointer Dereference

Level 2

Inner Page Table

📄

Indexed by p2 bits. Dynamically allocated only when virtual memory range is touched.

Contains 1024 Page Table Entries (PTEs)Stores the physical Frame Number (PFN) and page protection flagsConcatenated with Offset d to access the target physical DRAM byte

The Sparsity Advantage:

If a virtual memory range (e.g., $1\text{ GB}$ of unused address space between heap and stack) has no allocated pages, the corresponding entry in the Outer Page Directory is simply marked Invalid ($V = 0$). Zero inner page tables are allocated in RAM for that entire range!

A process using only $10\text{ MB}$ of memory consumes only a few kilobytes of page tables, instead of the full $4\text{ MB}$.

---

📐 Mathematical Derivation of Multi-Level Address Splitting

To ensure page tables can be allocated dynamically without external fragmentation, every page table at every level must fit completely inside exactly one physical Frame/Page!

📐The Golden Sizing Law of Hierarchical Pagingtheorem

$\text{Capacity of One Page Table Level} = \frac{\text{Page Size}}{\text{PTE Size}} = \frac{2^d}{2^e} = 2^{d - e}\text{ entries}$

Therefore, the maximum number of index bits allocated to any level $p_i$ is strictly bounded by: $\mathbf{p_i \le d - e}$

1. Two-Level Paging Bit-Splitting (Standard 32-Bit System)

• Virtual Address Space: $32\text{ bits}$ ($n = 32$).
• Page Size: $4\text{ KB} = 2^{12}\text{ bytes} \implies d = 12\text{ bits}$.
• Page Table Entry Size: $4\text{ bytes} = 2^2\text{ bytes} \implies e = 2$.
• Total Page Number bits: $p = n - d = 32 - 12 = 20\text{ bits}$.

Applying the sizing law: $\text{Entries per page} = \frac{4\text{ KB}}{4\text{ B}} = 1024 = 2^{10}\text{ entries}$

• Inner Page Table Index ($p_2$): Requires $\log_2(1024) = \mathbf{10\text{ bits}}$.
• Outer Page Directory Index ($p_1$): Remaining bits = $p - p_2 = 20 - 10 = \mathbf{10\text{ bits}}$.

x86 Two-Level PagingTotal Frame: 32 Bits Wide

Two-Level 32-Bit Logical Address Decomposition

Hierarchical bit splitting: Page Directory Index (p1) + Page Table Index (p2) + Offset (d)

Page Directory Index (p1)

10 Bits [31..22] MSB

Page Table Index (p2)

10 Bits [21..12] Middle

Page Offset (d)

12 Bits [11..0] LSB

10 Bits [31..22] MSBPage Directory Index (p1)

Indexes into the top-level Page Directory (1024 entries). Points to the base of the target Inner Page Table.

2. Multi-Level EMAT Formula (The Latency Trade-off)

While multi-level paging dramatically saves RAM capacity, it multiplies translation latency on a TLB miss! For a $k$-level page table:

• Accessing the target frame requires reading $k$ page tables in DRAM, plus $1$ access for the final data word: $\text{Total Memory Accesses on TLB Miss} = \mathbf{k + 1}$

$\mathbf{\text{EMAT}_{k\text{-level}} = c \times (t + m) + (1 - c) \times (t + (k + 1)m)}$

For a 4-level page table (e.g., x86-64) with $m = 100\text{ ns}$ and no TLB: $\text{Memory Access Time} = 5 \times 100\text{ ns} = \mathbf{500\text{ ns (400\% slowdown!)}}$ This proves that modern 64-bit multi-level paging is completely unusable without a high-hit-rate TLB!

---

🏭 Real-World Production Context:

1. The x86-64 4-Level Paging Architecture (PML4)

Modern AMD64 and Intel 64 processors implement a 48-bit canonical virtual address space using 4-Level Paging:

x86-64 / AMD64 StandardTotal Frame: 48 Canonical Bits

x86-64 Canonical 48-Bit Virtual Address Breakdown (PML4)

4-Level hierarchical paging structure standardized in modern 64-bit operating systems

PML4 Index

9 Bits [47..39] Bytes

PDPT Index

9 Bits [38..30] Bytes

PD Index

9 Bits [29..21] Bytes

PT Index

9 Bits [20..12] Bytes

Offset (d)

12 Bits [11..0] Bytes

9 Bits [47..39] BytesPML4 Index

Indexes Page Map Level 4 (512 entries). CR3 register points to the base of this table.

Why 9 bits per level? Because: $\text{Entries per page} = \frac{\text{Page Size}}{\text{PTE Size}} = \frac{4\text{ KB}}{8\text{ bytes}} = 512 = 2^9 \implies \mathbf{9\text{ bits per level}}$ $9 + 9 + 9 + 9 + 12 = 48\text{ bits total}$.

2. Multi-Core TLB Shootdowns & Process Context Identifiers (PCID)

In a multi-threaded system running across 64 CPU cores:

• When one core modifies a page mapping (e.g., calling mprotect() or munmap()), all other 63 cores may hold stale copies of that mapping in their local TLBs.
• The initiating core must broadcast an Inter-Processor Interrupt (IPI) to all other cores, forcing them to flush their TLBs. This expensive hardware stall is called a TLB Shootdown, causing noticeable latency spikes in high-concurrency systems.
• To prevent full TLB invalidations on normal thread context switches, modern CPUs support PCID (Process Context Identifiers) on x86-64 and ASID (Address Space Identifiers) on ARM. Each TLB entry is tagged with its owner's process ID, allowing multiple processes to share the TLB simultaneously without flushes!

---

📐 Numerical Applications & Worked Examples

Example 1: EMAT Derivations Across Single-Level vs Multi-Level Paging

Problem Statement:
A computing system has a TLB access time of $10\text{ ns}$ and a Main Memory access time of $80\text{ ns}$. The TLB hit ratio is $90\%$ ($0.90$). Assume that when a TLB miss occurs, the TLB is accessed first, and memory accesses are strictly sequential.

1. Compute the Effective Memory Access Time (EMAT) for a single-level page table.
2. Compute the EMAT if the system upgrades to a 3-level hierarchical page table.
3. What minimum TLB hit ratio ($c$) is required under the 3-level system to achieve an EMAT of less than $100\text{ ns}$?

Step-by-Step Solution:

1. EMAT for Single-Level Paging ($k = 1$):

   • TLB Hit: Requires TLB access ($t$) + RAM access for data ($m$).
   • TLB Miss: Requires TLB access ($t$) + RAM access for PTE ($m$) + RAM access for data ($m$) = $t + 2m$. $\text{EMAT} = c \times (t + m) + (1 - c) \times (t + 2m) = t + (2 - c)m$ $\text{EMAT} = 10 + (2 - 0.90) \times 80 = 10 + (1.10 \times 80) = 10 + 88 = \mathbf{98\text{ ns}}$

2. EMAT for 3-Level Paging ($k = 3$):

   • On a TLB miss, the MMU must traverse 3 levels of page tables in RAM before accessing data: $\text{Miss Latency} = t + (k + 1)m = t + 4m$ $\text{EMAT} = c \times (t + m) + (1 - c) \times (t + 4m)$ $\text{EMAT} = 0.90 \times (10 + 80) + 0.10 \times (10 + 4 \times 80)$ $\text{EMAT} = 0.90 \times 90 + 0.10 \times (10 + 320) = 81 + 0.10 \times 330 = 81 + 33 = \mathbf{114\text{ ns}}$

3. Required TLB Hit Ratio ($c$) for $\text{EMAT} < 100\text{ ns}$: $\text{EMAT} = c(t + m) + (1 - c)(t + 4m) < 100$ $c(90) + (1 - c)(330) < 100$ $90c + 330 - 330c < 100$ $-240c + 330 < 100 \implies 230 < 240c \implies c > \frac{230}{240} \approx \mathbf{95.83\%}$ The TLB hit ratio must be at least $95.84\%$ to sustain sub-$100\text{ ns}$ access.

---

Example 2: Determining Number of Paging Levels and Bit Allocation

Problem Statement:
A 48-bit virtual address architecture uses hierarchical paging. The Page Size is $16\text{ KB}$ and each Page Table Entry (PTE) takes $8\text{ bytes}$. Hardware architecture dictates that every Page Table at every level must fit entirely within a single page frame.

1. Calculate the number of entries that fit in one page table.
2. Determine the minimum number of paging levels required.
3. Specify the exact bit-field allocation of the logical address $[p_1, p_2, \dots, p_k, d]$.

Step-by-Step Solution:

1. Capacity of One Page Table Frame:

   • $\text{Page Size} = 16\text{ KB} = 16 \times 2^{10} = 2^4 \times 2^{10} = 2^{14}\text{ bytes} \implies d = 14\text{ bits}$.
   • $\text{PTE Size } e = 8\text{ bytes} = 2^3\text{ bytes}$. $\text{Entries per Page Table} = \frac{\text{Page Size}}{\text{PTE Size}} = \frac{2^{14}}{2^3} = 2^{11} = \mathbf{2048\text{ entries}}$ Therefore, each intermediate index field can have at most $\log_2(2^{11}) = \mathbf{11\text{ bits}}$.

2. Calculate Total Virtual Page Number (VPN) Bits:

   • $\text{Virtual Address} = 48\text{ bits}$.
   • $\text{Total Page Bits } p = 48 - d = 48 - 14 = \mathbf{34\text{ bits}}$.

3. Determine Number of Levels ($k$):

   • If $k = 3$ levels: Maximum page bits = $3 \times 11 = 33\text{ bits}$ (Insufficient to cover 34 bits!).
   • If $k = 4$ levels: Maximum page bits = $4 \times 11 = 44\text{ bits} \ge 34\text{ bits}$ (Sufficient!). Therefore, the architecture strictly requires 4 levels of paging.

4. Logical Address Bit Allocation: Allocating from the lowest level upwards:

   • Level 1 (Inner PT): $p_4 = 11\text{ bits}$.
   • Level 2 (Middle PT): $p_3 = 11\text{ bits}$.
   • Level 3 (Middle PT): $p_2 = 11\text{ bits}$.
   • Level 4 (Top Directory): $p_1 = 34 - (11 + 11 + 11) = 34 - 33 = \mathbf{1\text{ bit}}$.

   $\mathbf{\text{Logical Address} = [p_1: 1\text{ bit} \mid p_2: 11\text{ bits} \mid p_3: 11\text{ bits} \mid p_4: 11\text{ bits} \mid d: 14\text{ bits}]}$

---

Example 3: Memory Footprint: Flat Table vs Two-Level Page Table

Problem Statement:
A 32-bit system uses $4\text{ KB}$ pages and $4\text{ B}$ PTEs. A small process occupies only $16\text{ MB}$ of virtual memory, mapped contiguously starting from address 0x00000000.

1. Calculate the size of the Page Table under a single-level flat design.
2. Calculate the exact physical memory consumed by the page tables under a 2-level paging scheme (where the top-level Page Directory has 1024 entries and each inner table has 1024 entries).
3. Compute the percentage of memory saved by adopting the 2-level architecture.

Step-by-Step Solution:

1. Single-Level Flat Page Table: A flat page table must pre-allocate an entry for every virtual page in the $4\text{ GB}$ space, regardless of whether it is used:

   • $\text{Pages} = 2^{32 - 12} = 2^{20}\text{ pages}$. $\text{Flat PTS} = 2^{20} \times 4\text{ bytes} = \mathbf{4\text{ MB}}$

2. Two-Level Page Table Structure:

   • Each entry in the top-level Page Directory covers: $1024\text{ pages} \times 4\text{ KB per page} = \mathbf{4\text{ MB of virtual memory}}$
   • The process occupies $16\text{ MB}$ of memory: $\text{Page Directory Entries Needed} = \frac{16\text{ MB}}{4\text{ MB}} = \mathbf{4\text{ entries}}$
   • Physical memory allocated:
     • Top-Level Page Directory: Always allocated in RAM $\implies 1\text{ page} = \mathbf{4\text{ KB}}$.
     • Inner Page Tables: Only $4$ inner page tables are allocated to service the 4 active entries $\implies 4 \times 4\text{ KB} = \mathbf{16\text{ KB}}$.
     • Remaining $1020$ Page Directory entries are marked Invalid ($V = 0$), requiring zero inner tables!

   $\text{Total 2-Level PTS} = 4\text{ KB (Directory)} + 16\text{ KB (Inner Tables)} = \mathbf{20\text{ KB}}$

3. Percentage Memory Saved: $\text{Memory Saved} = \frac{4\text{ MB} - 20\text{ KB}}{4\text{ MB}} = \frac{4096\text{ KB} - 20\text{ KB}}{4096\text{ KB}} = \frac{4076}{4096} \approx \mathbf{99.51\%}$

The hierarchical structure eliminates $99.51\%$ of page table memory overhead!

---

🎯 Exam & Interview Pitfall Check

Core Conceptual Questions

• Question 1: Why does a multi-level page table increase memory access time on a TLB miss, yet modern systems universally adopt it?
  Answer: Because hardware memory is finite. Without multi-level paging, a 64-bit system would require $32\text{ Petabytes}$ of physical RAM just to hold the flat page table of a single process—an impossible requirement. Modern systems accept the $k+1$ memory access penalty on a miss because a well-designed TLB achieves a $98\text{--}99\%$ hit rate, rendering the multi-level walk penalty nearly invisible in practice.

• Question 2: What is the primary purpose of the Address Space Identifier (ASID) or Process Context Identifier (PCID) in a TLB?
  Answer: In older processors without ASID/PCID, every OS context switch between Process A and Process B forced the kernel to completely flush (invalidate) the entire TLB to prevent Process B from accessing Process A's cached physical translations. Tagging each TLB entry with an ASID/PCID allows translations from multiple processes to coexist simultaneously in the TLB without security violations, dramatically speeding up context switches.

• Question 3: In multi-level paging, why must each sub-table fit exactly inside one page frame?
  Answer: If a page table spanned multiple non-contiguous frames, the processor would need another translation mechanism just to find the pieces of the page table! Restricting each sub-table to $\le \text{Page Size}$ allows the OS to allocate and swap page tables using the exact same standard frame allocation routines used for user data.

Common Interview Traps

• Trap 1: Forgetting the Final Data Access in Multi-Level Memory Count.
  For a $k$-level page table, a common trap is assuming a TLB miss takes $k$ memory accesses. It takes $k + 1$ accesses: $k$ accesses to traverse the $k$ levels of page tables in RAM, plus $1$ additional access to read or write the actual data byte at the physical address!

• Trap 2: Assuming TLB Miss Means Page Fault.
  A TLB miss simply means the translation is not cached in fast on-chip CAM. The MMU walks the page table in RAM. If the PTE has $V = 1$, the page is safely in RAM and execution proceeds immediately. A Page Fault only occurs if the PTE in RAM has $V = 0$ (page is on disk).

• Trap 3: Allocating Level Bits Without Respecting Frame Capacity.
  When asked to design a 3-level address scheme, never arbitrarily split page bits (e.g., assigning $14$ bits to an inner table when the page size only supports $11$ bits). Always verify that $2^{p_i} \times \text{PTE Size} \le \text{Page Size}$.

---

🗺️View Complete COA Roadmap & Syllabus

← Previous Topic3.1 Virtual Memory Foundations & Hardware Paging MechanicsNext Topic →3.3 Inverted Page Tables, Segmentation & EMAT Performance Analysis