Master Linux Memory Management: Virtual & Physical Memory Explained

Virtual Address

Linux uses a virtual memory system that gives each process a 4 GB virtual address space, isolated from other processes. The virtual address is only mapped to a physical page when the process actually accesses the memory, triggering a page‑fault.

Virtual memory works like a cloud storage service: you are allocated a large logical space (e.g., 1 TB) but physical storage is only assigned as you store data.

Benefits of Virtual Address

Avoids direct access to physical memory, protecting the OS from destructive operations.

Each process can use an address space larger than the actual physical RAM.

The 4 GB virtual space is split into user space (0x00000000‑0xBFFFFFFF, 3 GB) and kernel space (0xC0000000‑0xFFFFFFFF, 1 GB).

Physical Address

When a process accesses a virtual address, the kernel’s Memory Management Unit (MMU) translates it to a physical address using segmentation and paging. The conversion process is described in most computer architecture textbooks.

Linux divides physical memory into three zones:

ZONE_DMA

Pages from 0 MB to 16 MB, used by legacy ISA devices via DMA.

ZONE_NORMAL

Pages from 16 MB to 896 MB, directly mapped into the kernel address space.

ZONE_HIGHMEM

Pages above 896 MB, not directly mapped; accessed via temporary or permanent mappings.

User Space

User processes operate within the user space region (0x00000000‑0xBFFFFFFF). The process address space is divided into five regions based on access attributes: code segment, data segment, BSS segment, heap, and stack.

Code segment : contains executable instructions; read‑only.

Data segment : holds initialized global/static variables.

BSS segment : holds uninitialized globals; cleared to zero at load time.

Heap : grows upward, used for dynamic allocations via malloc.

Stack : grows downward, stores local variables and call frames.

In the i386 architecture, the heap expands upward while the stack expands downward, which can lead to fragmentation if not managed carefully.

You can view the size of each segment for a compiled binary with the size command:

[lemon ~]# size /usr/local/sbin/sshd
   text    data     bss     dec     hex filename
1924532   12412   426896 2363840  2411c0 /usr/local/sbin/sshd

Kernel Space

On a 32‑bit x86 system, kernel virtual addresses range from 0xC0000000 to 0xFFFFFFFF (1 GB). This area contains the kernel image, page tables, and driver code.

Direct Mapping Region

The first 896 MB of kernel space is a direct‑mapping region where virtual address = physical address + PAGE_OFFSET (0xC0000000). The kernel can translate addresses with virt_to_phys().

High‑Memory Linear Region

The remaining 128 MB (0xF8000000‑0xFFFFFFFF) is used for high‑memory mappings, accessed via special APIs because it cannot be directly mapped.

Dynamic Mapping Region (vmalloc)

Allocated with vmalloc, this region provides contiguous virtual addresses but the underlying physical pages may be non‑contiguous. Allocation is limited between vmalloc_start and vmalloc_end.

Permanent Mapping Region

High‑memory pages can be permanently mapped using kmap after allocation with alloc_page(_GFP_HIGHMEM).

Fixed Mapping Region

A small fixed area (4 KB) at the top of the kernel address space is reserved for special purposes such as ACPI tables.

Physical Page Management Algorithms

Linux employs the Buddy system to allocate physical pages, grouping free pages into blocks of sizes that are powers of two (1, 2, 4, 8, … 1024 pages). This reduces external fragmentation because any request can be satisfied by splitting a larger block.

Example: requesting 4 pages when no 4‑page block is free causes the allocator to split an 8‑page block, allocate one half, and return the other half to the free list.

Slab Allocator

For small kernel objects (e.g., task_struct, file_struct), the Buddy system is inefficient. The slab allocator caches objects of the same type, reducing allocation overhead and internal fragmentation. Each slab consists of one or more physical pages and is managed in three lists: slabs_full, slabs_partial, and slabs_empty.

Allocation steps:

If slabs_partial has free objects, allocate from there; move the slab to slabs_full if it becomes full.

If slabs_partial is empty, allocate a new slab from slabs_empty and move it to slabs_partial.

If no empty slabs exist, request a new page from the Buddy system and create a fresh slab.

Virtual Memory Allocation in User Space

malloc

allocates user‑space virtual memory. For requests < 128 KB it uses brk/sbrk; larger requests use mmap. Frequent system calls cause performance overhead, and the heap grows upward, potentially leading to fragmentation.

Modern implementations use memory pools: a large block is obtained once, then subdivided into smaller chunks to satisfy malloc calls, reducing system‑call overhead.

Virtual Memory Allocation in Kernel Space

kmalloc

allocates virtual memory within the kernel’s direct‑mapping region and is backed by the slab allocator. It is used for small allocations and freed with kfree. You can inspect kmalloc caches via cat /proc/slabinfo (e.g., kmalloc-8, kmalloc-16).

vmalloc

allocates memory in the dynamic mapping region ( vmalloc_start ‑ vmalloc_end). The virtual addresses are contiguous, but the underlying physical pages may be scattered. It is typically used for large buffers, I/O driver structures, or kernel modules, and is freed with vfree.

Useful Commands

Inspect buddy allocator status:

[lemon]]# cat /proc/buddyinfo
Node 0, zone      DMA      1      0      0      0      2      1      1      0      1      1      3 
Node 0, zone    DMA32   3198   4108   4940   4773   4030   2184    891    180     67     32    330 
Node 0, zone   Normal  42438  37404  16035   4386    610    121     22      3      0      0      1

View slab allocator statistics: # cat /proc/slabinfo Real‑time slab cache monitoring with slabtop:

# slabtop

Conclusion

Linux memory management combines virtual address translation, zone‑based physical memory organization, and two complementary allocators—the Buddy system for page‑level allocation and the Slab allocator for small kernel objects. Understanding these mechanisms provides a solid foundation for performance tuning, debugging memory‑related bugs, and succeeding in technical interviews.