Linux Kernel Memory Management Architecture: SLUB Allocator Per-CPU Freelist Fastpaths, 5-Level Page Table Walks, and Transparent Huge Page (THP) TLB Coherency

In high-throughput database storage engines, low-latency trading matching engines, and multi-terabyte in-memory caches running on modern multi-socket NUMA servers, application tail latency ($p_{99.9}$) is frequently dictated not by instruction execution throughput, but by the virtual memory translation and kernel object allocation mechanics of the Linux Kernel Memory Management (`mm`) subsystem. Every network packet buffer (struct sk_buff), virtual filesystem inode (struct inode), and virtual memory area descriptor (struct vm_area_struct) relies on sub-page kernel memory allocation, while user-space memory references depend on hardware Memory Management Unit (MMU) radix page-table walks cached inside CPU Translation Lookaside Buffers (TLBs). Eliminating microsecond allocation stalls, cross-socket NUMA lock contention, and inter-processor TLB shootdown storms requires a rigorous mastery of the Zonal Buddy Allocator, the Unqueued SLUB Slab Allocator (`struct kmem_cache_cpu`), 4-level and 5-level (LA57) hardware page-table hierarchies, and Transparent Huge Page (THP) versus explicit `hugetlbfs` memory compaction mechanics.

1. Physical Page Frame Management: NUMA Zones, Buddy Lists & `struct folio`

At the base of the Linux physical memory hierarchy, system DRAM is partitioned across Non-Uniform Memory Access (NUMA) nodes (pg_data_t / struct pglist_data) and subdivided into hardware-constrained memory zones (ZONE_DMA32, ZONE_NORMAL, and ZONE_MOVABLE). To prevent external fragmentation across physical page frames of base size $4\text{ KiB}$ ($2^{12}\text{ bytes}$ on x86_64), the kernel's Zonal Buddy Allocator maintains arrays of free physical page blocks grouped by allocation order $k \in [0, \text{MAX\_PAGE\_ORDER}]$ (typically orders $0$ through $10$, spanning $4\text{ KiB}$ single pages up to $4\text{ MiB}$ contiguous blocks of $2^{10} = 1,024$ pages).

Historically, the kernel tracked every physical $4\text{ KiB}$ frame via a $64\text{-byte}$ struct page metadata descriptor, creating ambiguity when functions accepted pointers that could refer either to a single base page or the tail page of a compound multi-page allocation. Modern Linux kernels unify multi-page physical memory management around struct folio—a type-safe wrapper guaranteed to point exclusively to the head page (`PG_head`) of a power-of-two physical memory allocation, eliminating redundant compound-head pointer dereferences (`compound_head()`) across the page cache, anonymous memory faults, and slab allocators.

2. The Unqueued SLUB Allocator: Lockless Per-CPU `kmem_cache_cpu` Fastpaths

Because the Zonal Buddy Allocator operates strictly at page granularity ($\ge 4\text{ KiB}$), allocating sub-page kernel structures (such as a $256\text{-byte}$ struct sk_buff header or a $192\text{-byte}$ struct dentry) directly from the buddy system would waste over $90\%$ of system RAM to internal fragmentation. To serve high-frequency object allocations in $\sim 15\text{ to }35\text{ CPU cycles}$, the Linux kernel defaults to the Unqueued SLUB Allocator, which eliminates the complex per-CPU queue arrays of legacy SLAB in favor of a three-tier lockless hierarchy per slab cache (struct kmem_cache):

1. Tier 1 — Lockless Per-CPU Active Slab (struct kmem_cache_cpu): Each logical CPU core owns a private kmem_cache_cpu structure pointing to a currently active slab folio (page) and a lockless singly-linked list of free objects (freelist). When kernel code invokes kmem_cache_alloc() on the fastpath, the CPU atomically pops the head object off c->freelist using a lockless double-word compare-and-swap instruction (this_cpu_cmpxchg_double on the pointer and transaction ID tid)—requiring zero spinlocks and zero disabling of hardware interrupts.
2. Tier 2 — Per-Core Partial Slab List (c->partial): When the active per-CPU slab's freelist is exhausted (`NULL`), SLUB checks the CPU's local list of partially full slabs (kmem_cache_cpu->partial). If available, the head partial slab is promoted to become the new active CPU slab without touching cross-core locks.
3. Tier 3 — Per-NUMA-Node Partial Slab List (struct kmem_cache_node): Only when both the per-CPU active freelist and per-CPU partial list are empty does execution enter the slowpath (___slab_alloc()), acquiring the per-NUMA-node spinlock (n->list_lock) to pull a batch of partial slabs from kmem_cache_node, or invoking alloc_pages() from the Zonal Buddy Allocator to initialize a brand-new slab folio.

3. Hardware Radix Page Tables (4-Level vs. 5-Level LA57) & Hugepage Topologies

On 64-bit x86_64 and ARM64 architectures, user-space and kernel virtual addresses are translated into physical DRAM addresses via a hardware-walked multi-level radix tree rooted in the CPU's control register (CR3 on x86_64; TTBR0_EL1 / TTBR1_EL1 on ARM64). Standard 4-level paging translates a $48\text{-bit}$ virtual address space ($256\text{ TiB}$) across four $9\text{-bit}$ table indices ($512$ entries of $8\text{ bytes}$ per $4\text{ KiB}$ table page): Page Global Directory (PGD) $\to$ Page Upper Directory (PUD) $\to$ Page Middle Directory (PMD) $\to$ Page Table Entry (PTE). On massive memory servers configured with Intel 5-Level Paging (LA57, $128\text{ PiB}$ virtual address space), the kernel inserts a fifth level—the Page 4th Directory (P4D)—between PGD and PUD.

To prevent workloads with multi-hundred-gigabyte working sets from suffering constant L2 STLB misses (each triggering a $4\text{- or }5\text{-memory-reference}$ hardware page walk), the kernel short-circuits the radix tree at the PMD level ($2\text{ MiB}$ hugepage) or PUD level ($1\text{ GiB}$ gigantic page) by setting the hardware Page Size (`PS` / `PSE`) bit:

4. Transparent Huge Page (THP) Compaction Stalls & TLB Shootdown Mitigation

While Transparent Huge Pages (THP) automatically promote anonymous memory regions into $2\text{ MiB}$ PMD mappings without requiring application source-code changes, setting /sys/kernel/mm/transparent_hugepage/enabled to always coupled with aggressive synchronous defragmentation introduces two well-documented tail-latency hazards in latency-sensitive databases (such as Redis,RocksDB, and PostgreSQL):

• Synchronous Direct Compaction Stalls on Page Faults: After hours of uptime, physical RAM fragments into non-contiguous $4\text{ KiB}$ pages. When a thread triggers an anonymous page fault and attempts to allocate an Order-9 ($2\text{ MiB}$ contiguous) folio with defrag=always, the faulting thread synchronously invokes the kernel memory compaction scanner (compact_zone())—migrating movable pages across physical frames and stalling the application thread for $5\text{ to }40\text{ ms}$. Production systems mitigate this by configuring enabled=madvise and defrag=defer+madvise, waking the asynchronous background kernel daemon (kcompactd and khugepaged) while immediately falling back to a $4\text{ KiB}$ PTE if an Order-9 block is not instantly free.
• Copy-on-Write (`fork()`) Amplification & TLB Shootdown Storms: When a memory-intensive process executes fork() (e.g., for background persistence snapshots) or calls munmap() / madvise(MADV_DONTNEED) on a $4\text{ KiB}$ sub-slice of a $2\text{ MiB}$ THP, the kernel must invoke split_huge_pmd() to shatter the single PMD entry into $512$ individual $4\text{ KiB}$ PTEs. Updating or unmapping shared page-table entries forces the kernel to issue synchronous TLB Shootdown Inter-Processor Interrupts (IPIs) via flush_tlb_mm_range() across every CPU core running threads of that process—halting remote execution pipelines until all cores execute hardware INVLPG / INVLPGB instructions and acknowledge the shootdown barrier.

Primary Linux Kernel & Hardware Architecture References

• 1. Linux Kernel Core Documentation: The SLUB Unqueued Slab Allocator — Per-CPU Lockless Freelists, Partial Slab Management, and `kmem_cache` Internals.
• 2. Linux Kernel Virtual Memory Subsystem: Transparent Hugepage Support (THP), Multi-Size THP (mTHP), `khugepaged` Collapse Scanning, and Defragmentation Modes.
• 3. Intel 64 and IA-32 Architectures Software Developer's Manual (Volume 3A): 4-Level and 5-Level (LA57) Radix Paging Structures, Translation Lookaside Buffers (TLBs), and Page-Walk Caches.