Chapter 17: Architecture-Specific Implementations and Source Walkthroughs

Updated

October 31, 2026

Chapter 17: Architecture-Specific Implementations and Source Walkthroughs

While the Linux memory management subsystem presents a unified set of generic concepts—such as struct page, struct vm_area_struct, and the buddy allocator—the actual implementation must adapt to the physical realities of different CPU microarchitectures.

How page tables are traversed, how caching attributes are encoded, how TLB invalidations are broadcast across processor cores, and how hardware devices access memory via DMA differ substantially across x86-64, ARM64, and RISC-V.

This chapter explores the architecture-specific abstractions in the Linux kernel source tree, compares memory handling across hardware platforms, analyzes DMA and IOMMU mappings, and provides a guide to navigating and compiling the kernel.

The Architecture Abstraction Layer

The Linux kernel bifurcates memory management into two distinct source trees:

Generic Core (mm/): Architecture-neutral algorithms. Contains page_alloc.c (buddy allocator), slub.c, memory.c (page faults), mmap.c, vmscan.c (reclaim), and filemap.c (page cache).
Architecture Support (arch/<arch>/mm/): Hardware-specific drivers and assembly routines. Contains page table manipulation macros, TLB flushing routines, fault handlers (fault.c), and initialization setup (init.c).

┌────────────────────────────────────────────────────────────────────────┐
│               GENERIC MM VS ARCHITECTURE ABSTRACTION                   │
│                                                                        │
│                        Generic Core (mm/)                              │
│       ┌─────────────────┬──────────────────┬─────────────────┐         │
│       │  Buddy Allocator│  SLUB Allocator  │   Page Cache    │         │
│       │  (page_alloc.c) │     (slub.c)     │   (filemap.c)   │         │
│       └────────┬────────┴────────┬─────────┴────────┬────────┘         │
│                │                 │                  │                  │
│   PTE / PMD / PUD Macros         │         TLB Flush / Shootdown       │
│   (set_pte_at, pte_present)      │         (flush_tlb_page)            │
│                │                 │                  │                  │
│                ▼                 ▼                  ▼                  │
│       ┌─────────────────┬──────────────────┬─────────────────┐         │
│       │   arch/x86/mm/  │  arch/arm64/mm/  │  arch/riscv/mm/ │         │
│       │  (CR3, Invlpg,  │   (TTBR0/1,      │   (SATP, SFENCE,│         │
│       │   SMP IPI TLB)  │    TLBI, MAIR)   │    Sv39/48/57)  │         │
│       └─────────────────┴──────────────────┴─────────────────┘         │
└────────────────────────────────────────────────────────────────────────┘

The interface contract between mm/ and arch/<arch>/mm/ is defined by macro contracts like set_pte_at(), pte_present(), pmd_page(), and flush_tlb_range().

Architectural Comparison: x86-64 vs. ARM64 vs. RISC-V

Architectural Feature	x86-64	ARM64 (AArch64)	RISC-V
Page Table Base Register	Single register: `CR3`	Split registers: `TTBR0_EL1` (User) & `TTBR1_EL1` (Kernel)	Single register: `satp` (Supervisor Address Translation & Protection)
Paging Modes	4-level (48-bit VA) / 5-level (57-bit VA)	3-level / 4-level (48-bit or 52-bit VA with LVA)	Sv39 (3-level), Sv48 (4-level), Sv57 (5-level)
Supported Page Granules	4 KiB, 2 MiB, 1 GiB	4 KiB, 16 KiB, 64 KiB (configurable in kernel)	4 KiB, 2 MiB, 1 GiB (Gigapage), 512 GiB (Terapage)
TLB Invalidation Mechanism	Software IPI broadcasts (`smp_call_function`)	Hardware broadcast instructions (`tlbi`)	Software IPI broadcasts via SBI (Supervisor Binary Interface)
Memory Consistency Model	TSO (Total Store Order) - Strong ordering	Weakly Ordered - Requires explicit barriers (`dmb`, `dsb`, `isb`)	RVWMO (RISC-V Weak Memory Ordering) - `fence` instructions

ARM64 Memory Management and MAIR

ARM64 handles virtual memory with distinct hardware primitives designed for power efficiency and virtualization:

1. Split Translation Tables: TTBR0 and TTBR1

Unlike x86-64, where user space and kernel space share a single root page table pointer in CR3, ARM64 divides the 64-bit virtual address space in half at the hardware level: - Addresses with high bits 0x0000... match TTBR0_EL1 (User Space). - Addresses with high bits 0xffff... match TTBR1_EL1 (Kernel Space).

When switching user tasks, the kernel writes the new user page table pointer to TTBR0_EL1. The kernel mappings in TTBR1_EL1 remain untouched. This eliminates the need for expensive kernel page table duplication and softens the performance impact of address space isolation.

2. Memory Attribute Indirection Register (MAIR_EL1)

In x86-64, caching attributes (e.g., Uncacheable, Write-Back, Write-Through) are determined by bit flags (PWT, PCD, PAT) spread across page table entries.

In ARM64, page table entries do not store raw cache attributes directly. Instead, they store a 3-bit index (AttrIndx[2:0]) pointing into MAIR_EL1:

MAIR_EL1 Register: [ Attr7 | Attr6 | Attr5 | Attr4 | Attr3 | Attr2 | Attr1 | Attr0 ]
                         │
PTE: [ ... | AttrIndx=010b | ... ] ──► Reads Attr2 = Normal Inner/Outer Write-Back Cacheable

The Linux kernel configures MAIR_EL1 during boot in arch/arm64/mm/proc.S, assigning slots for Normal Cacheable RAM, Device Non-Gathering/Non-Reordering (Device-nGnRE for MMIO), and Non-Cacheable memory.

RISC-V Paging Modes: Sv39, Sv48, and Sv57

RISC-V formalizes virtual memory through modular addressing standards:

┌────────────────────────────────────────────────────────────────────────┐
│                        RISC-V PAGING FAMILIES                          │
│                                                                        │
│   Sv39: 3-level page walk (39-bit VA = 512 GiB address space)          │
│         VPN[2] (9b) ─► VPN[1] (9b) ─► VPN[0] (9b) ─► Offset (12b)      │
│                                                                        │
│   Sv48: 4-level page walk (48-bit VA = 256 TiB address space)          │
│         VPN[3] (9b) ─► VPN[2] ─► VPN[1] ─► VPN[0] ─► Offset (12b)      │
│                                                                        │
│   Sv57: 5-level page walk (57-bit VA = 128 PiB address space)          │
│         VPN[4] (9b) ─► VPN[3] ─► VPN[2] ─► VPN[1] ─► VPN[0] ─► Offset   │
└────────────────────────────────────────────────────────────────────────┘

The translation mode is configured in the satp (Supervisor Address Translation and Protection) control register: - MODE field (bits 63:60): 0 = Bare (direct physical), 8 = Sv39, 9 = Sv48, 10 = Sv57. - PPN field (bits 43:0): Physical Page Number of the root page table.

TLB Shootdown Mechanisms: Hardware vs. Software

When a thread unmaps a page or marks a PTE read-only, all CPU cores caching that translation must flush their TLBs before the memory can be reused:

x86-64 Software IPI TLB Shootdowns

x86 processors lack hardware-level cross-core TLB broadcast instructions. The kernel must execute a software dance: 1. Originating core prepares a TLB flush descriptor. 2. Originating core fires an Inter-Processor Interrupt (IPI) across the APIC bus to all target CPUs. 3. Target CPUs pause execution, execute the invlpg assembly instruction, and acknowledge completion via memory fences. 4. Originating core waits for all acknowledgments before proceeding.

Under heavy multi-threaded memory reallocation, IPI storm overhead can consume significant CPU time.

ARM64 Hardware TLB Broadcast

ARM64 provides hardware-assisted TLB invalidation instructions:

/* Flush virtual address range across all cores in the inner shareable domain */
tlbi vaae1is, x0
dsb ish
isb

The CPU broadcast hardware automatically invalidates the TLB entry across all cores in the coherency domain without invoking software interrupt handlers or halting executing threads.

Direct Memory Access (DMA) and the IOMMU

Peripheral hardware devices (e.g., NVMe controllers, 100GbE NICs, GPUs) read and write host RAM directly without CPU intervention via DMA.

┌────────────────────────────────────────────────────────────────────────┐
│                   DMA WITHOUT AND WITH AN IOMMU                        │
│                                                                        │
│ 1. Direct Physical DMA (Insecure; Contiguous Buffer Required):         │
│   [ Network Card ] ───────► Physical Bus ───────► Physical RAM         │
│   (Vulnerable to malicious bus-mastering devices)                      │
│                                                                        │
│ 2. DMA with IOMMU (Address Translation & Access Protection):           │
│   [ Network Card ] ──► Device Virtual Address (IOVA)                   │
│                              │                                         │
│                              ▼                                         │
│                      ┌───────────────┐                                 │
│                      │     IOMMU     │                                 │
│                      │  (Intel VT-d  │ (Translates IOVA to PFN;        │
│                      │   ARM SMMU)   │  Blocks unauthorized frames)    │
│                      └───────┬───────┘                                 │
│                              ▼                                         │
│                        Physical RAM                                    │
└────────────────────────────────────────────────────────────────────────┘

The IOMMU (Input-Output Memory Management Unit)

Address Translation: Maps non-contiguous physical pages into a contiguous Input-Output Virtual Address (IOVA) space, eliminating the need for expensive high-order contiguous physical buffer allocations.
Memory Protection: Restricts device access strictly to the physical pages mapped in the IOMMU page table, preventing compromised hardware from reading host secrets.

DMA APIs in Kernel:

/* Map a buffer for device streaming DMA */
dma_addr = dma_map_single(dev, buffer_va, size, DMA_FROM_DEVICE);
if (dma_mapping_error(dev, dma_addr))
    goto err;
/* Tell device to DMA into dma_addr ... */
dma_unmap_single(dev, dma_addr, size, DMA_FROM_DEVICE);

Navigating the Linux Kernel Source Tree

When researching memory management algorithms or debugging low-level behavior, focus on these key source files:

linux/
├── mm/                           # Architecture-generic memory management
│   ├── page_alloc.c              # The Buddy Allocator (alloc_pages, rmqueue)
│   ├── slub.c                    # The SLUB object allocator
│   ├── memory.c                  # Core page fault handling (handle_mm_fault)
│   ├── mmap.c                    # Virtual memory areas, brk, mmap, munmap
│   ├── vmscan.c                  # Page reclaim, LRU lists, kswapd
│   ├── compaction.c              # Two-pointer memory defragmentation
│   ├── rmap.c                    # Reverse mapping (page -> PTEs)
│   ├── memcontrol.c              # Memory cgroups v2 controller
│   └── oom_kill.c                # Out-of-memory victim selection
│
├── arch/x86/mm/                  # x86-64 specific implementation
│   ├── fault.c                   # Hardware page fault ISR (do_user_addr_fault)
│   ├── tlb.c                     # SMP TLB shootdown IPI routines
│   ├── pgtable.c                 # Page table allocation and manipulation
│   └── kaslr.c                   # Early boot KASLR randomization
│
└── arch/arm64/mm/                # ARM64 specific implementation
    ├── fault.c                   # Data/Instruction Abort handling
    ├── mmu.c                     # TTBR0/TTBR1 initialization & MAIR setup
    └── context.c                 # ASID (Address Space ID) management

Compiling and Booting a Custom Hardened Kernel

To test kernel memory patches or compile an optimized, stripped-down kernel for high-performance memory workloads, follow this build procedure:

# 1. Download stable Linux kernel source
git clone --depth 1 --branch v6.12 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux

# 2. Copy current host configuration as starting baseline
cp -v /boot/config-$(uname -r) .config

# 3. Update configuration and enable specific MM hardening flags
make olddefconfig
scripts/config --enable CONFIG_SLAB_FREELIST_HARDENED
scripts/config --enable CONFIG_SLAB_FREELIST_RANDOM
scripts/config --enable CONFIG_INIT_ON_ALLOC_DEFAULT_ON
scripts/config --enable CONFIG_INIT_ON_FREE_DEFAULT_ON
scripts/config --enable CONFIG_TRANSPARENT_HUGEPAGE_MADVISE

# 4. Compile the kernel and loadable modules (-j = core count)
make -j$(nproc) bindeb-pkg LOCALVERSION=-custom-mm

# 5. Install the generated Debian/Ubuntu packages
sudo dpkg -i ../linux-image-*-custom-mm_*.deb ../linux-headers-*-custom-mm_*.deb

# 6. Update GRUB and verify installation
sudo update-grub
sudo reboot

After rebooting into the custom kernel, verify your new virtual memory subsystem parameters:

uname -a
grep -E "SLAB_FREELIST|INIT_ON" /boot/config-$(uname -r)

Key Takeaways

The Linux memory subsystem cleanly separates architecture-neutral logic (mm/) from architecture-specific hardware control (arch/<arch>/mm/).
ARM64 decouples user and kernel page tables at the hardware level using split TTBR0/TTBR1 registers and simplifies caching through MAIR_EL1 indirection.
RISC-V implements modular page table walks across Sv39, Sv48, and Sv57 standards managed by the satp register.
TLB invalidation illustrates distinct design philosophies: software IPI coordination on x86-64 versus hardware-broadcast instructions (tlbi) on ARM64.
IOMMUs translate and isolate device DMA requests, preventing hardware devices from reading unmapped physical memory frames.