Introduction

RAM is a sparsely populated map, not a bucket of bytes. Your 16GB laptop can run processes asking for 100TB of memory. How? The Kernel lies.

Virtual Memory is the art of promising distinct memory addresses to every process while mapping them to the same physical chips-or often, to nothing at all.

---

The Physics: Translation Lookaside Buffer (TLB)

The CPU does not know “Physical RAM”. It only knows Virtual Addresses. Every memory access requires a translation: Virtual -> Physical. Reading the Page Table from RAM takes 100ns. This doubles the cost of every memory access.

The Fix: The TLB. A tiny hardware cache that remembers “Virtual Page 5 = Physical Frame 900”. TLB Hit: 0ns overhead. TLB Miss: 100ns (Page Walk).

Physics: If your working set exceeds the TLB size, your program slows down by 50%, even if you have infinite RAM. This is why HugePages (2MB instead of 4KB) exist-to increase TLB coverage.

---

Deep Dive: The SLAB Allocator

malloc() is slow. It searches for free blocks. The Kernel needs to allocate millions of identical objects (e.g., task_struct, inode).

The Solution: SLAB (and SLUB). Pre-allocated caches of specific object sizes.

• Need a task_struct? Take one off the top of the task_struct_cache stack.
• Freeing? Just push it back on the stack.
• Zero Fragmentation. Zero Searching.

---

The Assassin: OOM Killer

When RAM + Swap is full, the Kernel must kill something. It doesn’t pick randomly. It calculates a score.

$Score = \text{RAM Usage (\%)} + \text{Root Bonus} + \text{OOM Adjustment}$

1. Badness: High memory usage (1000 points max).
2. Protection: Root processes get a -30 points discount.
3. Adjustment: You can manually set /proc/<pid>/oom_score_adj to -1000 to become invincible (like sshd).

---

Code: Inspecting the Maps

Where is your heap? Where is your stack? cat /proc/self/maps tells the truth.

# Output format:
# address           perms offset  dev   inode       pathname
00400000-00452000 r-xp 00000000 08:02 173521      /usr/bin/zsh  (Text)
00651000-00652000 r--p 00051000 08:02 173521      /usr/bin/zsh  (Data)
01cea000-01d0d000 rw-p 00000000 00:00 0           [heap]
...
7ffeeb9a0000-7ffeeb9c1000 rw-p 00000000 00:00 0   [stack]

Key Insight: Notice r-xp (Read-Execute-Private) for code, and rw-p for data. You cannot write to code. You cannot execute data (NX Bit). This prevents Buffer Overflows.

---

Practice Exercises

Exercise 1: The Page Fault (Beginner)

Scenario: malloc(1GB). Task: Does the OS allocate 1GB of RAM? No. It allocates “Virtual Promises”. The RAM is allocated only when you touch (write to) the pages (Minor Page Faults). Verify this with ps (VSZ vs RSS).

Exercise 2: OOM Survival (Intermediate)

Task:

1. Run a process.
2. echo -1000 > /proc/<pid>/oom_score_adj.
3. Trigger an OOM condition (safely!).
4. Confirm your process survives while others die.

Exercise 3: HugePages (Advanced)

Task: Check /proc/meminfo for HugePages_Total. Enable HugePages and run a memory-intensive database (like Postgres). Measure the performance difference (TLB Miss reduction).

---

Knowledge Check

1. Why do HugePages improve performance?
2. What is the difference between specific Major and Minor Page Faults?
3. Why does the Kernel generally refuse to kill sshd during OOM?
4. What is the “NX Bit”?
5. Does free() return memory to the OS immediately?

Answers

1. TLB Efficiency. One TLB entry covers 2MB instead of 4KB. Fewer misses.
2. Major: Disk I/O required (Swap/File). Minor: Memory mapping only (First access/COW).
3. Safety. sshd allows the admin to log in and fix the problem. Killing it locks you out.
4. No-Execute. Hardware flag that prevents code execution in Data/Stack segments.
5. No. Usually, glibc keeps the memory in the heap for reuse. It is only returned (via sbrk) if a large chunk at the end is freed.

---

Summary

• Virtual Memory: A lie that enables isolation.
• TLB: The hardware cache that makes the lie fast.
• OOM: The grim reaper of memory leaks.

---