The kernel is the ultimate memory manager. Every byte of RAM is tracked, every allocation goes through the kernel. Understanding how Linux allocates, tracks, and reclaims memory helps you tune servers, debug OOM crashes, and write efficient code.
Physical vs Virtual Memory
What's the difference between physical and virtual memory?
Physical memory is your actual RAM chips. Virtual memory is the address space each process sees — it can be larger than physical RAM. The kernel maintains a mapping table (page table) that translates virtual addresses to physical ones. This lets every process think it has exclusive access to memory, even when sharing with hundreds of other processes.
Memory Zones
Linux divides physical memory into zones, primarily for compatibility with older hardware:
Zone
Range (x86-64)
Purpose
DMA
0–16MB
For old ISA devices that can only access low addresses
DMA32
16MB–4GB
For 32-bit devices on 64-bit systems
Normal
4GB+
General purpose — most allocations happen here
The Buddy Allocator
How does the kernel hand out RAM to processes?
Through the buddy allocator — it manages pages (4KB chunks) grouped into power-of-2 blocks. Need 12KB? Get a 16KB block (4 pages). When you free it, the buddy allocator tries to merge adjacent free blocks back into larger ones, preventing fragmentation.
# See buddy allocator state
cat /proc/buddyinfo
# Node 0, zone Normal 2534 1156 641 298 131 61 30 15 5 3 1
# Numbers = free blocks of 2^n pages (4KB, 8KB, 16KB, 32KB...)
The Slab Allocator
The buddy allocator works in pages (4KB minimum). But the kernel constantly needs much smaller objects — a 200-byte inode, a 64-byte task_struct. The slab allocator sits on top of the buddy allocator and provides small object caches:
Pre-allocates pools of common-sized objects
Reuses freed objects without returning to buddy allocator
Much faster for frequent small allocations
cat /proc/slabinfo | head -10
# name active num_objects obj_size slabs
# inode_cache 12045 15000 592 ...
# dentry 38421 40000 192 ...
Memory Overcommit
Why does Linux promise more memory than it has?
Programs often allocate memory they never actually use. fork() creates a full copy of the parent, but most of those pages are never touched. Linux overcommits — it hands out virtual memory addresses beyond what physical RAM+swap can support, betting that not all of it will be used at once.
This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.
How should I use this page?
Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.
What should I read next?
Use the navigation below to continue to the next lesson or explore related topics.