The Linux memory management subsystem hasn’t had a definitive reference since 2004. The Linux Memory Manager fills this void with a modern, in-depth exploration of how Linux handles memory, combining high-level overviews with detailed code analysis.
Written by a Linux kernel maintainer and supported by insights from memory management experts, this book provides readers with a rare opportunity to explore the subsystem at both the conceptual and code levels.
This 1,300-page guide goes beyond surface explanations, showing how core principles are implemented in the Linux kernel source and serving as both a study guide and an on-the-job reference for years to come.
This book targets Linux 6.0.
AI Reading Assistant
Whole-book reading guide from stratified index samples; jump to passages in the text
Tip the Site
Support this siteYour recognition and a small knowledge-service contribution help keep this technical work open source.Scan the WeChat Pay or Alipay code below. Logged-in and guest visitors can both tip.
WeChat Pay
Alipay
Open WeChat or Alipay and scan. No login required.
AI guide
【One-Line Pitch】
A modern, code-level reference to how Linux actually manages physical and virtual memory, written by a kernel maintainer and aimed at engineers who need to reason about the subsystem rather than just skim its man pages. Best for kernel developers, systems programmers, and performance engineers working on Linux 6.0-era kernels.
【Book Arc】
- **Opening (~0%–10%)**: Frames the memory subsystem's core data structures — `struct page`, zones, nodes, and per-CPU page sets — establishing the vocabulary and layout assumptions (modern 64-bit, little-endian) used throughout.
- **Early (~10%–25%)**: Walks the physical page allocator in depth, from GFP flags and `__alloc_pages()` through the buddy allocator's free/merge logic, plus early boot-time page table and direct-mapping setup.
- **Early–Middle (~25%–35%)**: Covers kernel virtual address space machinery — vmalloc area bookkeeping, page-table population helpers, and PGD sharing across processes, including PTI complications.
- **Middle (~35%–50%)**: Shifts to process memory: VMA flags and semantics, overcommit accounting, the ELF image layout, and the `brk()`/`mmap()` allocation paths, including VMA merge and split rules.
- **Late (beyond ~50%)**: Excerpts do not cover the later chapters in detail; the book's structure suggests reclaim, swap, slab, compaction, and cgroup memory topics follow, but this guide cannot map them from the sampled material.
- **Ending**: Excerpts do not cover the closing chapters; no reliable summary of the book's final sections can be given here.
【Key Takeaways】
- **`struct page` is the atom of physical memory management** (Opening): a 64-byte, cache-line-sized descriptor packing flags, refcount, mapcount, and a type-dependent metadata union — understanding it unlocks everything downstream.
- **Zones and nodes are the spatial hierarchy** (Opening): NUMA nodes and DMA/DMA32/NORMAL zones partition memory by access characteristics, and allocation policy is expressed through them.
- **Per-CPU page sets exist to avoid lock contention** (Opening): free pages are cached per core, with batching and high-water marks tuned to reduce cross-CPU traffic and false sharing.
- **The buddy allocator is a merge-and-split machine** (Early): `__free_one_page()` merges buddies upward, while allocation walks down from the smallest sufficient order — fragmentation behavior follows directly from this.
- **Allocation is a two-phase fast/slow path** (Early): `__alloc_pages()` tries `get_page_from_freelist()` first and only falls into `__alloc_pages_slowpath()` (direct reclaim) when the fast path fails.
- **Kernel virtual mappings are shared across processes** (Early–Middle): PGD entries for kernel space are copied at process creation, so P4D-and-below kernel changes propagate globally — a key simplification worth internalizing.
- **VMAs encode policy, not just address ranges** (Middle): flags like `VM_WIPEONFORK`, `VM_NORESERVE`, `VM_ACCOUNT`, and `VM_HUGEPAGE` determine fork behavior, overcommit accounting, and THP eligibility.
- **VMA merging is a constrained operation** (Middle): `vma_merge()` only combines neighbors when flags and boundaries permit, and ephemeral flags like `VM_SOFTDIRTY` are explicitly excluded from the mergeability test.
【Reading Tips】
- Deep-read the `struct page` and zone/node material early; later chapters assume this vocabulary and the 64-byte layout mental model.
- Treat the allocator call-stack walkthroughs as the spine of the early chapters — trace `__alloc_pages()` → `get_page_from_freelist()` → `__rmqueue*` on paper once, then skim subsequent listings.
- Skim the exhaustive page-flag combination tables (e.g., x86-64 `__PAGE_KERNEL_*` matrices) on first pass; return to them as reference when a specific mapping type appears.
- When reading VMA flag descriptions, keep a running note of which flags affect fork, overcommit, and merging — these are the ones that surface in real debugging.
- Use the book as an on-the-job reference after a first linear read; the code listings are indexed well enough to revisit by topic.
【Coverage Limits】
This guide is based on stratified excerpts covering roughly the first half of the book (through process memory and VMAs); later chapters on reclaim, swap, slab, and cgroups are not represented, so their treatment here is deliberately omitted rather than summarized.
Excerpt 1
is struct page which, for mod- ern 64-bit systems contains: • A flags field which specifies attributes of the page and additionally en- codes zone and option...
vmap_pages_pte_range() does more, as shown in Listing 3-65. 457 static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr, 206 Chapter 3 The Linux Memor...
() allocator expands and shrinks this region in response to userland allocation requests which is typically used for smaller allocations, with larger ones de...
t set up the struct anon_vma object associated with the VMA if one does not already exist via anon_vma_prepare() – this checks the struct vm_area_struct (VMA...
ia page_move_anon_rmap() as shown in Listing 7-24. 1092 /** 1093 * page_move_anon_rmap - move a page to our anon_vma 1094 * @page: the page to move to our an...
folio() (eliding out of scope device mapping logic):- 65 /* 66 * Return the folio with ref appropriately incremented, 67 * or NULL if that failed. 68 */ 69 s...
try avoiding (again, we must do this in either case qas the mapping itself may no longer exist). If we maintained the lock, we unpin the folio via folio_put(...
Support this siteYour recognition and a small knowledge-service contribution help keep this technical work open source.
Scan the WeChat Pay or Alipay code below. Logged-in and guest visitors can both tip.
WeChat PayAlipay
Open WeChat or Alipay and scan. No login required.
Add Tag
Enter tag name (max 50 characters)
Share E-Book
The Linux Memory Manager (Lorenzo Stoakes)(Z-Library)
Scan QR code with your phone to access
Copy the link or scan the QR code to access this e-book on your phone
Share E-Book via Email
Please enter email address
Donation Statistics
¥.00
Total Donations
0
Donation Count
The Linux Memory Manager (Lorenzo Stoakes)(Z-Library)
Find Your Favorite Books
Only registered users can comment after logging in. Comments need to be reviewed by administrators before being displayed
Loading comments...
Reply to Comment
Edit Comment