Fundamentals 22 min read

Master Linux Memory Management: Virtual, Physical, and Kernel Allocation Explained

This comprehensive guide walks through Linux memory management fundamentals, covering virtual address spaces, physical memory zones, user‑space structures, kernel allocation strategies like the buddy system and slab allocator, and practical commands for inspecting memory usage.

Liangxu Linux
Liangxu Linux
Liangxu Linux
Master Linux Memory Management: Virtual, Physical, and Kernel Allocation Explained

Linux memory management relies on virtual memory to give each 32‑bit x86 process a 4 GB isolated address space, mapping virtual addresses to physical pages only when accessed. The virtual address space is split into user space (0x00000000‑0xBFFFFFFF) and kernel space (0xC0000000‑0xFFFFFFFF), each with distinct purposes.

Virtual Address Basics

Virtual memory allows the OS to allocate memory on demand, similar to cloud storage allocating space only when files are uploaded. Each process works with virtual addresses; the kernel creates page‑table entries to map them to physical memory when a page fault occurs.

Benefits of Virtual Addresses

Protects the system by preventing direct physical memory access.

Provides each process with an address space larger than the actual RAM.

The 4 GB virtual space is divided into user and kernel regions, illustrated by the accompanying diagram.

Physical Memory Layout

Linux classifies physical memory into three zones:

ZONE_DMA : 0‑16 MB, used by legacy ISA devices via DMA.

ZONE_NORMAL : 16‑896 MB, directly mapped into kernel space.

ZONE_HIGHMEM : >896 MB, accessed via temporary or permanent mappings.

These zones are visualized in the "Physical Memory Partition" diagram.

User‑Space Memory Regions

A process’s user space is further divided into five areas, each with specific access attributes:

Code segment – read‑only executable instructions.

Data segment – initialized global/static variables.

BSS segment – zero‑filled uninitialized globals.

Heap – dynamically allocated memory (malloc, brk/sbrk, mmap).

Stack – function call frames and local variables.

The layout follows the classic i386 model where the stack grows downward and the heap upward.

Kernel‑Space Memory Management

Kernel space (0xC0000000‑0xFFFFFFFF) contains the kernel image, page tables, and driver data. It is split into:

Direct‑mapping region (first 896 MB) – linear addresses map directly to physical addresses with a fixed offset (PAGE_OFFSET = 0xC0000000).

High‑mem linear region (next 128 MB) – requires explicit mapping via virt_to_phys() or similar.

Dynamic mapping region (vmalloc area) – allocated with vmalloc, linear but not necessarily physically contiguous.

Permanent mapping region – used for high‑mem pages via kmap or alloc_page(GFP_HIGHMEM).

Fixed mapping region – small, fixed‑address slots for special hardware (e.g., ACPI_BASE).

Buddy System

The kernel’s buddy allocator manages free pages in power‑of‑two blocks (1, 2, 4 … 1024 pages). When a request cannot be satisfied, a larger block is split; when blocks are freed, adjacent buddies are merged, reducing external fragmentation.

[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

Slab Allocator

For small kernel objects (task_struct, file_struct, etc.), the buddy system would be inefficient. The slab allocator builds caches ( kmem_cache) of pre‑allocated objects, reducing internal fragmentation and allocation overhead. Each cache maintains three lists: slabs_full, slabs_partial, and slabs_empty. Allocation proceeds by trying slabs_partial, then slabs_empty, and finally requesting a new page from the buddy system.

If slabs_partial has free slots, allocate and move to slabs_full when exhausted.

If not, check slabs_empty, allocate a new slab, and move it to slabs_partial.

If both are empty, request a new page from the buddy system and repeat.

Commands to inspect slab usage include cat /proc/slabinfo, slabtop, and cat /proc/slabinfo | grep kmalloc for kmalloc‑based caches.

Virtual Memory Allocation

In user space, malloc obtains memory via brk/sbrk for small allocations (<128 KB) and mmap for larger ones. To avoid frequent system calls, modern malloc implementations use memory pools, carving large chunks into suitably sized blocks.

In kernel space, two primary APIs exist: kmalloc / kfree – allocate small, physically contiguous blocks from the direct‑mapping region, backed by the slab allocator. vmalloc / vfree – allocate larger, virtually contiguous blocks in the dynamic mapping region; physical pages may be scattered.

Summary

Linux memory management combines virtual address abstraction, zone‑based physical memory organization, and two complementary allocators (buddy for pages, slab for objects) to balance performance, fragmentation, and flexibility. Understanding these layers helps developers reason about memory usage, debug allocation issues, and perform well‑informed interviews.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

LinuxUser Spacebuddy systemSlab AllocatorKernel Space
Liangxu Linux
Written by

Liangxu Linux

Liangxu, a self‑taught IT professional now working as a Linux development engineer at a Fortune 500 multinational, shares extensive Linux knowledge—fundamentals, applications, tools, plus Git, databases, Raspberry Pi, etc. (Reply “Linux” to receive essential resources.)

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.