Every time you run a program, the Linux kernel gives it a private, standardized view of memory called the process address space. It doesn't matter how much physical RAM your computer has or what other programs are running. From your program's perspective, it has the whole place to itself, neatly organized into distinct regions.

This virtual layout is consistent for every process:

• Text & Data: At the bottom are the program's machine code (text) and initialized global variables (data).
• Heap: This is for dynamically allocated memory, like when you call malloc() in C. It grows upward from the data segment.
• Memory Mapping Segment: This area holds shared libraries and files mapped directly into memory.
• Stack: Used for local variables and function calls. It starts at a high address and grows downward.

Crucially, the vast space between the heap and the stack is just empty virtual address space. No physical memory is used until it's actually needed. This clean separation between user space, where applications run, and kernel space, where the operating system manages everything, is a core security and stability feature.

So, how does the CPU turn a virtual address from your program into a real, physical location in RAM? This translation is handled by a piece of hardware called the Memory Management Unit (MMU), which is part of the CPU. The kernel sets up a series of lookup tables, called page tables, for the MMU to use.

Linux uses a multi-level page table hierarchy to make this efficient. Imagine it as a series of nested address books. For a 64-bit system, this typically involves four levels:

1. Page Global Directory (PGD)
2. Page Upper Directory (PUD)
3. Page Middle Directory (PMD)
4. Page Table Entry (PTE)

When a program accesses a virtual address, the MMU breaks it into pieces. Each piece serves as an index into one of these tables. The PGD points to an entry in the PUD, which points to an entry in the PMD, which points to the final PTE. This final entry, the PTE, contains the physical address of the memory page, along with permission bits (read, write, execute).

Walking through four tables for every single memory access would be incredibly slow. To speed this up, the MMU has a small, fast cache called the Translation Lookaside Buffer (TLB). The TLB stores recently used virtual-to-physical address translations.

When the CPU needs to access memory, the MMU first checks the TLB. If the translation is there (a TLB hit), it's used immediately. If not (a TLB miss), the MMU has to perform the slow page table walk. The result is then cached in the TLB for future use. When the kernel modifies the page tables, it must explicitly flush the corresponding entries from the TLB to ensure the CPU doesn't use stale data.

Virtual memory isn't just for isolating processes. It also provides a powerful mechanism for file I/O called memory mapping. Instead of reading a file piece by piece, a process can ask the kernel to map the entire file into its address space using the mmap() system call.

When a file is memory-mapped, the kernel sets up PTEs to point to the physical pages in the page cache that hold the file's data. Initially, the data isn't actually loaded into RAM. Only when the program tries to access a part of the mapped region does a page fault occur. The kernel then intercepts this fault, loads the required page from the disk into memory, and resumes the program.

This technique, known as demand paging, is extremely efficient. It avoids unnecessary data copies and lets the kernel manage memory intelligently. It's how shared libraries work: the same physical copy of a library's code in RAM can be mapped into the virtual address space of many different processes.

Ready to check your understanding of these core concepts?

Understanding how the kernel abstracts hardware through virtual memory is fundamental to seeing how modern operating systems provide a stable and secure environment for applications to run.