Logical vs Physical Address Space

When your program reads from memory address 0x7fff5fbff58c, it is not accessing the physical memory chips at that physical location. That address is a logical address — a construct that the CPU resolves through the memory management unit (MMU) before any byte hits the actual DRAM. The OS and hardware collaborate to give each process the illusion of a contiguous, exclusive address space, even when physical memory is fragmented, shared, and smaller than the logical address space your code uses.

Understanding the distinction between logical and physical addresses is foundational to reasoning about memory protection, virtual memory, and the security boundaries that keep your processes from crashing — or spying on — each other.

When to Use / When Not to Use

The logical vs physical address distinction is always in effect — you cannot disable it on modern hardware. But understanding it matters most when:

When you benefit from knowing it:

• Debugging segmentation faults (was the fault caused by an invalid logical address or a protection violation?)
• Writing low-level systems code that interacts with the kernel (mmap, mprotect, shmget)
• Optimizing for TLB behavior (understanding which logical pages map to which physical frames)
• Understanding ASLR (Address Space Layout Randomization) and why it mitigates exploits

When you do not need to think about it:

• Writing application code in high-level languages (Python, JavaScript, Go)
• Web services and API handlers
• Standard CRUD operations where the runtime handles memory

The distinction becomes unavoidable when you write C/C++ with manual memory management, or when you work with kernel-level code, device drivers, or any system that calls mmap() or mprotect() directly.

Architecture or Flow Diagram

The address translation path flows from your program’s logical address through the MMU’s translation process, consulting the TLB and page tables before reaching physical memory.

flowchart TD
    CPU["CPU Issues<br/>Logical Address"]
    MMU["MMU<br/>Memory Management Unit"]
    TLB["TLB<br/>Translation Lookaside Buffer"]
    PT["Page Tables<br/>in Physical Memory"]
    DRAM["Physical DRAM"]
    PF["Page Fault?<br/>Exception Handler"]
    PGFAULT["OS Page Fault<br/>Handler"]

    CPU --> MMU
    MMU --> TLB
    TLB -->|"Hit"| DRAM
    TLB -->|"Miss"| PT
    PT -->|"Valid entry"| DRAM
    PT -->|"Invalid entry"| PGFAULT
    PGFAULT -->|"Page loaded"| DRAM
    PGFAULT -->|"Protection fault"| PGFAULT

    style PF stroke:#ff6b6b
    style PGFAULT stroke:#ff6b6b

The MMU first checks the TLB for a cached virtual-to-physical translation. On a TLB miss, it walks the page tables (stored in physical memory) to find the mapping. If the page is not in physical memory, the OS loads it from disk and updates the page tables. If the access is invalid (protection violation), the OS delivers a segmentation fault to the process.

Core Concepts

Logical (Virtual) Address Space

The logical address space is what the CPU generates and what your program operates within. On a 64-bit system, the theoretical logical address space is 2^64 bytes — far larger than any physical memory installed. In practice, hardware and OS constraints limit this:

• Linux/x86-64: Uses 48-bit virtual addresses (256 TB address space), with the upper half reserved for the kernel
• Windows/x64: Uses 48-bit addresses with a different split between user and kernel halves
• ARM64: Supports 48-bit or 52-bit virtual addresses depending on the hardware implementation

The kernel sets up each process with its own isolated virtual address space. When process A writes to logical address 0x1000, it modifies whatever physical page that address maps to — completely independent of what process B has at its own 0x1000.

Physical Address Space

Physical addresses refer to actual hardware memory chips — the DRAM modules on your motherboard. The physical address space is bounded by installed RAM. A machine with 16 GB of DRAM has a 16 GB physical address space, regardless of how many processes are running or how large their combined virtual address spaces are.

Physical memory pages are not contiguous in terms of virtual addresses — page 0 and page 1 in virtual memory might map to physical pages 0x1A000 and 0x0034000. The OS maintains the mapping; the CPU enforces it.

Segmentation (Historical and Modern)

Segmentation predates paging as a memory management scheme. In pure segmentation, a logical address consists of a segment selector and an offset. The selector indexes a segment descriptor stored in the GDT (Global Descriptor Table) or LDT (Local Descriptor Table), which contains the base physical address and limit (size) of the segment. The CPU adds the offset to the base to produce the physical address.

x86 supports segmentation natively via the CS, DS, SS, ES, FS, GS segment registers. However, modern OSes (Linux, Windows) use flat segmentation — all segment bases are set to zero and limits are set to the maximum, effectively neutralizing segmentation and relying entirely on paging for memory protection and virtualization.

Linux does still use segmentation for specific purposes:

• The %fs segment register holds per-thread data (thread-local storage) on many Linux configurations
• The %gs register is used for stack protector canaries and other thread-specific data

The MMU and Address Translation

The Memory Management Unit is hardware dedicated to translating logical addresses to physical addresses on every memory access. On x86, the MMU is integrated into the CPU die. It operates in parallel with the cache hierarchy — physical addresses are used to index the L1 cache, so address translation must happen before or alongside cache lookup.

The translation uses a two-level structure on modern systems:

1. Page Directory (CR3 register points to this in physical memory)
2. Page Table entries pointed to by each page directory entry

The logical address is split into:

• Page directory index (bits 31-22)
• Page table index (bits 21-12)
• Page offset (bits 11-0)

The MMU walks these levels, checks protection bits, and produces a 44-bit physical frame number, then appends the 12-bit offset to produce a 56-bit physical address.

Production Failure Scenarios + Mitigations

Page Table Bloat in Large Mappings

Failure: Applications that memory-map large files (databases, machine learning models) can create page tables with millions of entries. Each level of the page table hierarchy consumes a full 4 KB page. For a 100 GB memory-mapped file with 4 KB pages, the page table hierarchy alone consumes ~100 MB of physical memory — memory that could serve as actual page cache for other workloads.

Mitigation: Use huge pages (2 MB or 1 GB pages on x86) for large mappings. PostgreSQL’s huge_pages setting, the Linux thp (transparent huge page) feature, and mmap(MAP_HUGETLB) all reduce page table overhead. The tradeoff is increased internal fragmentation (wasted space within each huge page).

TLB Shootdowns Under Heavy Context Switching

Failure: When the OS performs a context switch, it must invalidate all TLB entries for the outgoing process. On systems with many CPU cores, this TLB flush propagates across cores via IPIs (Inter-Processor Interrupts), causing a latency spike. Under heavy fork/exec activity, TLB shootdown cost can consume 10-20% of CPU time.

Mitigation: Linux includes ASID (Address Space ID) support on supported hardware, which tags TLB entries with a process identifier. This allows TLB entries from different processes to coexist without invalidation. Not all hardware supports ASID; on those that do not, every context switch invalidates the TLB. PCID (Process Context ID) on x86 implements ASID-like tagging.

Address Space Layout Randomization Collisions

Failure: ASLR randomizes where the stack, heap, libraries, and mmap regions load in the virtual address space. But entropy is limited — on a 64-bit system with 48-bit addresses, some regions have less randomization than expected due to alignment requirements. In certain conditions, a crafted ROP (Return-Oriented Programming) chain can bypass ASLR despite the randomization.

Mitigation: Use position-independent executables (PIE) (-fPIC -pie on GCC/Clang), which randomizes the entire address space including the main executable. Combine with RETL (Return FlowGuard) and BFG (Blitz Cookie FGuard) for layered exploit mitigation. On Linux, verify ASLR is active with cat /proc/sys/kernel/randomize_va_space (0=off, 1=stack-only, 2=full).

Trade-off Table

Aspect	Pure Segmentation	Pure Paging	Hybrid Segmentation + Paging
External fragmentation	High (segments must be contiguous in physical memory)	None (pages are uniform size)	Minimal
Internal fragmentation	None	~2 KB average per page (4 KB page, 2 KB average waste)	Same as paging
Memory protection granularity	Segment-level (coarse)	Page-level (4 KB, fine-grained)	Segment + page
Page table overhead	None (segment descriptors are small)	Multi-level page tables for large address spaces	Reduced (segment base + page offset)
TLB efficiency	High (one TLB entry per segment covers all addresses)	One TLB entry per page; large working sets exhaust TLB	Best of both (one entry per segment for commonly-used pages)
Complexity	Simple hardware	Moderate (page table walks)	High
Modern OS support	Neglected (flat segmentation only)	Universal (Linux, Windows, macOS all use paging)	Historical (80286 era); not used in modern general-purpose OSes

Implementation Snippets

Examining Your Virtual Address Space (C)

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>

/* Read and print the maps file that shows this process's
 * virtual address space layout. Each line describes a mapped
 * region: start-end perms offset device inode pathname */
void print_virtual_mappings(void) {
    FILE *maps = fopen("/proc/self/maps", "r");
    if (!maps) {
        perror("fopen /proc/self/maps");
        return;
    }

    char line[512];
    printf("%-18s %-10s %-6s %s\n",
           "Address range", "Permissions", "Offset", "Pathname");
    printf("%-18s %-10s %-6s %s\n",
           "-------------", "------------", "------", "--------");

    while (fgets(line, sizeof(line), maps)) {
        // Example line:
        // 00400000-0040c000 r-xp 00000000 fd:00 123456 /bin/bash
        printf("%s", line);
    }
    fclose(maps);
}

/* Show the logical vs physical address relationship.
 * On x86, page tables are in physical memory; we can read them
 * via the CR3 register (via read_cr3() on Linux) */
int main(void) {
    printf("Process ID: %d\n", getpid());
    printf("Logical address space on x86-64 is 48 bits (256 TB)\n");
    printf("Physical memory installed: ");
    FILE *meminfo = fopen("/proc/meminfo", "r");
    char line[256];
    while (fgets(line, sizeof(line), meminfo)) {
        if (strncmp(line, "MemTotal:", 9) == 0) {
            printf("%s", line);
            break;
        }
    }
    fclose(meminfo);

    print_virtual_mappings();
    return 0;
}

Translating Virtual to Physical Addresses (bash + ping)

#!/bin/bash
# Find the virtual-to-physical memory mapping for a target process
# Requires root for page table access

PID=$(pgrep -n ping | head -1)
if [ -z "$PID" ]; then
    echo "No ping process found"
    exit 1
fi

echo "Examining virtual address space for PID $PID:"
echo "---"

# /proc/PID/pagemap lets us translate virtual to physical pages
# (requires reading 8 bytes per virtual page)
PAGES=$(cat /proc/$PID/pagemap 2>/dev/null)
if [ -z "$PAGES ]; then
    echo "Cannot read pagemap (need root or pagemap capability)"
    exit 1
fi

# Show the memory maps for context
echo "Memory mappings for PID $PID:"
cat /proc/$PID/maps | head -20

Observability Checklist

• TLB hit/miss rates: perf stat -e dTLB-loads,dTLB-load-misses,dTLB-stores,dTLB-store-misses ./program
• Page fault frequency and type: cat /proc/PID/status — look at VmFault* fields; ps -o majflt,minflt shows major vs minor faults
• Page table walker events: perf stat -e page_walk_mgr_* (hardware-specific) for hardware page table walker activity
• Virtual memory map size: ps -o vsz,rss (virtual size vs resident set size) — large gap indicates memory-mapped files or swapped regions
• ASLR entropy: cat /proc/sys/kernel/randomize_va_space — should be 2 in production
• Large page usage: cat /proc/meminfo | grep -i huge — shows transparent huge page and explicit huge page statistics
• OOM (Out of Memory) killer: dmesg | grep -i "out of memory" or journalctl -k | grep -i oom — shows when the OOM killer invoked
• swapped pages: vmstat 1 — si and so columns show swap-in and swap-out rates

Security/Compliance Notes

Address Space Layout Randomization (ASLR): ASLR randomizes the base addresses of the stack, heap, libraries, VDSO, and mmap regions every time a process starts. This forces attackers to guess the address of usable code gadgets (for ROP attacks), rather than knowing them fixed. ASLR is effective against exploits that require knowing a memory address, but it does not protect against information leaks (e.g., Spectre-style timing attacks).

Kernel Address Space Layout Randomization (KASLR): Starting with Linux kernel 4.12, KASLR randomizes the kernel’s load address at boot. Without KASLR, a kernel stack overflow exploit could target known kernel symbol addresses. KASLR makes the kernel’s text segment base unpredictable, adding another layer to kernel exploit mitigation.

SMEP (Supervisor Mode Execution Prevention) and SMAP (Supervisor Mode Access Prevention): These CPU features (on Intel Skylake+ and AMD Zen+) prevent the kernel from executing user-space code (SMEP) or accessing user-space data (SMAP). Even if an exploit hijges kernel control flow, SMEP blocks jumping to user-space shellcode, and SMAP blocks the kernel from dereferencing pointers to user-space buffers (preventing data-only attacks via kernel data structure corruption).

Meltdown/Spectre Impact on Address Translation: The Meltdown vulnerability (CVE-2017-5754) exploited the fact that out-of-order speculative execution could execute memory accesses that should have faulted, populating the cache with data from the target address. The microcode patches (IBRS/STIBP) added serializing instructions to the address translation path, adding measurable latency to every system call and page table walk.

Common Pitfalls / Anti-patterns

Pitfall: Assuming virtual address spaces are not fragmented. The virtual address space can become fragmented through repeated mmap/munmap cycles, leaving gaps between mapped regions. When a large contiguous allocation is requested (e.g., a 10 MB mmap), the allocator may fail with ENOMEM even though the total free bytes exceeds 10 MB — because the free memory is not contiguous.

Pitfall: Writing to memory-mapped files without understanding write-back behavior. mmap with MAP_SHARED writes directly to the underlying file (or page cache). The write may not reach persistent storage immediately — the OS batches writes for performance. For durability-critical data, use msync() to force writes to storage, or open with MAP_POPULATE to pre-fault pages.

Pitfall: Confusing virtual memory with swap space. Virtual memory is the logical address space your OS presents. Swap is the backing store for pages not present in physical memory. A system can have abundant virtual address space but zero swap free — the OOM killer will invoke. Virtual address space exhaustion is different from physical memory exhaustion.

Anti-pattern: Pointer arithmetic assuming 32-bit addressing on a 64-bit system. On a 64-bit system, sizeof(void*) is 8 bytes. If you store a pointer in a 32-bit integer (uint32_t), you truncate the upper bits, silently corrupting the address. GCC’s -Wpointer-to-int-cast and -Wint-to-pointer-cast flags catch these. UBSan (Undefined Behavior Sanitizer) also detects them.

Quick Recap Checklist

• A logical (virtual) address is what the CPU generates; a physical address is what DRAM accepts
• The MMU translates logical to physical addresses on every memory access, with TLB as the translation cache
• Page tables stored in physical memory map virtual pages to physical frames; the MMU walks them on TLB misses
• Segmentation (base+limit) is obsolete in modern OSes; paging provides finer-grained protection and eliminates external fragmentation
• ASLR randomizes the virtual address space layout to prevent exploits from hardcoding memory addresses
• TLB shootdowns on context switches cause measurable latency spikes on systems without PCID/ASID support
• Page table bloat for large memory mappings can consume significant physical memory — huge pages mitigate this
• Virtual address space exhaustion (ENOMEM) is different from physical memory exhaustion (OOM killer invocation)
• Tools like /proc/PID/maps, /proc/PID/pagemap, and perf stat with TLB events reveal address translation behavior
• SMEP/SMAP prevent the kernel from executing or accessing user-space memory, closing exploit vectors

Interview Questions

Further Reading

• Concurrency Fundamentals — The problem space and why synchronization is needed
• Mutex Implementation — How mutexes are implemented in userspace and kernel
• Semaphores — Counting semaphores for resource management
• Readers-Writer Locks — Optimizing for read-heavy workloads
• Lock-Free Structures — Advanced techniques for highly concurrent systems

Conclusion

The distinction between logical and physical addresses is fundamental to how modern operating systems provide memory isolation, virtual memory, and security boundaries. The MMU translates every logical address through the TLB and page tables before any physical memory access occurs. This translation is invisible to programs but critical to system stability and security.

Logical address spaces on 64-bit systems are vast (256 TB on Linux/x86-64), but physical memory is finite and shared across all processes. The OS manages this illusion through multi-level page tables, which map virtual pages to physical frames only when needed. Copy-on-write optimizes fork() by deferring physical memory copies until writes occur. ASLR randomizes the layout of memory regions to prevent exploits from hardcoding addresses.

Understanding address translation helps when debugging crashes, optimizing for cache and TLB behavior, and reasoning about security boundaries. For your next step, explore paging and page tables to understand the data structures that make this translation possible, or virtual memory to see how the OS uses disk as a backing store when physical memory is exhausted.