Complete End-to-End Memory Access Control Path

 

Complete Control Flow of Memory Access

We’ll follow it from:

• 🖥 CPU issuing the memory request

• ⚡ Hardware translation

• 💥 Possible faults

• 💽 OS page fault handling

• 🔁 Final successful access

We can now roughly sketch the complete control flow of memory access.

In other words, when someone asks:

“What happens when a program fetches some data from memory?”

You should be able to describe all the different possibilities that may occur during that access.

---

📌 High-Level View

When a program fetches data from memory, the system may experience:

• ✅ A TLB hit

• 🔄 A TLB miss

• 📦 A page fault

• 🚫 A protection fault

• 💥 A segmentation fault

Each of these outcomes follows a specific control path.

---

🎯 Key Idea

To fully understand memory access, you must understand:

• The hardware translation path (TLB + page table checks)

• The software page-fault handling path (OS intervention)

Together, these two flows describe the complete end-to-end memory access process in a virtual memory system.

🔹 Hardware Control Flow (Figure 21.2)

The first control flow describes what the hardware does during address translation:

• Extract the Virtual Page Number (VPN)

• Look up the TLB

• If TLB miss → check the page table

• Verify:

  • Valid bit

  • Protection bits

  • Present bit

• Either:

  • Complete the memory access

  • Raise an exception (protection, segmentation, or page fault)

This part is entirely handled by the hardware.

---

🔹 Software Control Flow (Figure 21.3)

The second control flow describes what the Operating System does when a page fault occurs:

• Find a free physical frame

• If memory is full → evict a page

• Read the required page from disk

• Update the page table

• Retry the instruction

This part is handled by the OS page-fault handler.

---

🔷 STEP 1: CPU Generates a Virtual Address

When the program accesses memory:

Virtual Address = VPN | Offset

The CPU splits it into:

• VPN (Virtual Page Number) → identifies the page

• Offset → location inside the page

---

🔷 STEP 2: Check the TLB

Hardware checks the TLB.

---

✅ CASE A: TLB HIT (Fast Path 🚀)

1. VPN found in TLB

2. Check protection bits

   • If illegal → ❌ Protection Fault

3. Compute physical address:

   Physical Address = PFN | Offset
   

4. Access memory

5. Instruction completes

✔ Done (fast — nanoseconds)

---

❌ CASE B: TLB MISS

VPN not in TLB.

Hardware now looks in the page table.

---

🔷 STEP 3: Check Page Table Entry (PTE)

Hardware calculates:

PTEAddr = PTBR + (VPN × sizeof(PTE))

Reads PTE from memory.

Now three possibilities:

---

❌ CASE B1: Invalid Page

PTE.Valid == False

This means:

• Program accessed memory it does not own

• Example: bad pointer

➡ Hardware raises:

💥 Segmentation Fault

OS usually terminates the process.

---

🚫 CASE B2: Protection Violation

Access not allowed by PTE.ProtectBits

Example:

• Writing to read-only memory

• Executing non-executable memory

➡ Hardware raises:

🚫 Protection Fault

OS may terminate process.

---

📦 CASE B3: Page Is Valid

Now check:

---

🔹 CASE B3a: Page Present in Memory

PTE.Present == True

Meaning:

• Page is already in RAM

• Just not in TLB

What happens?

1. Insert entry into TLB

2. Retry instruction

3. Now TLB hit

4. Memory access succeeds

✔ Slightly slower than TLB hit
(still fast)

---

🔹 CASE B3b: Page NOT Present

PTE.Present == False

This means:

• Page is valid

• But swapped out to disk

➡ Hardware raises:

💥 PAGE FAULT

Now control transfers to the Operating System

---

🔷 STEP 4: OS Page Fault Handler Runs

The OS now takes over.

---

1️⃣ Find Free Frame

PFN = FindFreePhysicalPage()

If memory has space → good
If not → go to replacement

---

2️⃣ If Memory Full → Replace Page

PFN = EvictPage()

OS:

• Selects a victim page

• Writes it to disk (if modified)

• Frees that frame

---

3️⃣ Read Page From Disk

DiskRead(PTE.DiskAddr, PFN)

• Load needed page into RAM

• Process is blocked

• OS runs another process

⚠ This is very slow (milliseconds)

---

4️⃣ Update Page Table

PTE.Present = True
PTE.PFN = PFN

Now page is officially in memory.

---

5️⃣ Restart Instruction

RetryInstruction()

The CPU tries again.

---

🔷 STEP 5: Final Retries

After restart:

1. TLB miss (because TLB not updated yet)

2. Hardware inserts into TLB

3. Retry again

4. TLB hit

5. Memory access succeeds

✔ Finally completes

Full Flow Summary Diagram (Conceptual)

CPU generates virtual address
        ↓
Check TLB
        ↓
   ┌─────────────┬──────────────┐
   │             │              │
TLB Hit      TLB Miss      Protection Fault
   │             │
Access        Check Page Table
Memory            ↓
           ┌───────────────┬───────────────┬──────────────┐
           │               │               │
        Invalid        Present        Not Present
           │               │               │
   Segmentation       Update TLB       Page Fault
      Fault               │               │
                          │         OS Handles Fault
                          │               │
                          │       Load From Disk
                          │               │
                          └──────────── Retry ────────────→ Success

---

Key Differences Between Faults

Fault Type	Meaning
Segmentation Fault	Illegal memory reference
Protection Fault	Access type not allowed
Page Fault	Legal page, but on disk

---

Important Idea

Hardware handles:

• Address translation

• Protection checking

• Raising exceptions

OS handles:

• Page faults

• Disk I/O

• Page replacement

This explains how a system can use more memory than is physically available in RAM by relying on virtual memory and disk storage.

---

🔹 Key Concepts Introduced

1️⃣ Present Bit in Page Table

• Each page-table entry includes a present bit.

• It tells the system whether a page is:

  • ✅ Currently in physical memory

  • ❌ Stored on disk (swapped out)

This bit is essential for supporting memory larger than RAM.

---

2️⃣ What Happens If a Page Is Not Present?

When a program accesses a page that is not in memory:

• A page fault occurs.

• The OS page-fault handler runs.

• The OS:

  • Finds or frees a physical frame

  • Loads the page from disk into memory

  • Updates the page table

  • Restarts the instruction

If memory is full, the OS may first:

• Replace (evict) another page

• Possibly write it back to disk

---

🔹 Transparency to the Process

One of the most important ideas:

All of this happens completely transparent to the process.

From the program’s perspective:

• It has its own private, continuous memory space.

• Memory appears simple and contiguous.

Behind the scenes:

• Pages may be stored in non-contiguous physical frames.

• Some pages may not even be in memory.

• The OS and hardware manage everything automatically.

---

🔹 Performance Implications

• In the common case, memory access is fast.

• But in the worst case, a single instruction can:

  • Trigger a page fault

  • Require disk I/O

  • Take milliseconds to complete

Since disk is much slower than RAM, excessive page faults can drastically slow down a program.

---

🎯 Final Takeaway

Virtual memory allows systems to:

• Run programs larger than physical memory

• Provide isolation and simplicity to processes

• Automatically manage memory using disk as backup storage

However, this power comes with added complexity and potential performance costs when page faults occur.