从物理页到对象缓存：Linux内核内存管理的炼金术

深入解码Linux内核如何将原始物理内存转化为高效、可靠的多层分配体系

引言

操作系统内核的核心职责之一是管理物理内存资源。在Linux内核中，内存并非简单地以字节为单位分配，而是经过一套精密的多层抽象机制——从底层的物理页框分配器，到中层的对象缓存机制，再到高层的虚拟内存管理。这套机制不仅要应对碎片化、NUMA拓扑、内存压力等挑战，还要在纳秒级延迟约束下完成分配与回收。

本文将深入解析Linux内核内存管理的核心机制，涵盖伙伴系统、SLUB分配器、LRU回收算法及OOM-killer的工作原理，并结合内核源码片段与性能调优实战，帮助读者建立对内存管理子系统的完整认知。

一、物理内存模型

1.1 从UMA到NUMA

早期计算机系统采用UMA（Uniform Memory Access）架构，所有CPU访问内存的延迟相同。但随着多核处理器发展，NUMA（Non-Uniform Memory Access）成为主流：每个CPU节点拥有本地内存，跨节点访问需要经过互联总线（如Intel UPI或AMD Infinity Fabric），延迟增加50%-200%。

Linux内核通过pg_data_t结构描述每个NUMA节点：

typedef struct pglist_data {
    struct zone node_zones[MAX_NR_ZONES];    // 内存区域数组
    struct zonelist node_zonelists[MAX_ZONELISTS]; // 分配回退列表
    int node_id;                              // 节点ID
    struct page *node_mem_map;                // 页描述符数组
    unsigned long node_start_pfn;             // 起始页帧号
} pg_data_t;

1.2 内存区域（Zone）

每个节点划分为多个区域，满足不同DMA和映射约束：

• ZONE_DMA：0-16MB，用于遗留ISA DMA设备
• ZONE_DMA32：16MB-4GB，支持32位DMA设备
• ZONE_NORMAL：直接映射到内核线性地址空间（x86为896MB）
• ZONE_MOVABLE：可移动页面，用于内存热插拔
• ZONE_HIGHMEM（仅32位）：动态映射的高端内存

二、伙伴系统（Buddy System）

2.1 核心思想

伙伴系统是内核物理页框分配的基础算法。它将空闲页面按2的幂次分组（order 0至11，即4KB至8MB），每个order维护一个空闲链表。分配时向上分裂，释放时向下合并伙伴块，以此对抗外部碎片。

2.2 伙伴识别算法

两个块互为伙伴的条件：大小相同、地址连续、且低位在order+1位互补。内核用异或运算快速判断：

struct page *buddy = pagebase ^ (1UL << order);

对于第n页框、order为k的块，其伙伴页框为page_idx ^ (1 << k)。这意味着伙伴的二进制地址仅在第k位不同。

2.3 分配流程

// mm/page_alloc.c 核心逻辑简化
struct page *alloc_pages(gfp_t gfp_mask, unsigned int order) {
    // 1. 从目标zone的order空闲链表中获取
    page = rmqueue(zone, order, gfp_mask);
    if (!page) {
        // 2. 回退到伙伴系统更大order分裂
        page = __rmqueue_fallback(zone, order, gfp_mask);
    }
    if (!page) {
        // 3. 触发直接内存回收
        page = __alloc_pages_direct_reclaim(gfp, order);
    }
    return page;
}

2.4 碎片化与反碎片

伙伴系统仅解决"伙伴级"的外部碎片（即2^k对齐的碎片），但无法解决更小粒度的问题。为此Linux引入迁移类型分组：

• MIGRATE_UNMOVABLE：内核数据结构，不可移动
• MIGRATE_MOVABLE：用户页缓存、匿名页，可迁移
• MIGRATE_RECLAIMABLE：slab对象，可回收
• MIGRATE_ISOLATE：热插拔隔离

每个order链表按迁移类型分组，使得不同生命周期的页面聚合，便于回缩(compaction)。

三、SLUB分配器

3.1 为什么需要SLUB

伙伴系统以页（通常4KB）为粒度分配，但内核大量对象的尺寸仅为数百字节（如task_struct约1.9KB、inode约600B）。若在伙伴系统上直接分配，内部碎片率高达99.9%。SLUB（Unqueued Slab Allocator）解决此问题。

3.2 SLUB数据结构

struct kmem_cache {
    struct kmem_cache_cpu *cpu_slab;  // 每CPU快速路径
    struct kmem_cache_node *node[MAX_NUMNODES]; // NUMA节点慢速路径
    unsigned int size;                // 对象实际大小
    unsigned int object_size;         // 原始请求大小
    unsigned long flags;              // 对齐/追踪标志
    unsigned int offset;              // 空闲链表指针偏移
    struct list_head list;            // 全局缓存链表
};

struct kmem_cache_cpu {
    void **freelist;   // 空闲对象链表（快速路径）
    struct page *page; // 当前活跃slab页
    unsigned long tid; // 版本号避免ABA问题
};

3.3 三级分配路径

SLUB采用快慢分离策略：

1. Fast-path：检查cpu_slab->freelist是否有空闲对象。若有，CAS弹出首个对象并返回。全程无锁、无中断禁用，耗时约10-20ns。
2. Mid-path：freelist为空时检查当前page的partial链表。若page仍有未使用空间但需进入慢路径锁。
3. Slow-path：从NUMA节点的partial链表分配，最终调用伙伴系统获取新page。

3.4 CPU部分链表与NUMA感知

SLUB为每个CPU维护独立freelist（Multiple Queue），避免缓存行弹跳(bounce)。每个NUMA节点维护partial链表，优先本地分配。释放对象时通过page的node字段判断归属节点，若本地则还入freelist，否则还入对应节点的partial链表。这种NUMA感知设计使跨节点流量降低80%以上。

四、内存回收与页面缓存

4.1 LRU算法及其变体

Linux使用双链表LRU：active链表和inactive链表。页面被访问时移入active尾部，从active头部扫描降级至inactive，最后从inactive头部回收。这种防止了"仅一次访问"就驻留的问题，正确区分工作集和仅扫描页面。

// 页面老化监控
refcount = page_referenced(page, referenced_file_page);
if (refcount && page_is_file_cache(page))
    ClearPageReferenced(page);
if (refcount >= 2 && page_is_file_lru(page)) {
    // 频繁访问，从inactive提升至active
    activate_page(page);
}

4.2 Kswapd直接回收

当空闲页面低于low水位线时，唤醒kswapd内核线程异步回收。若kswapd回收速度跟不上分配需求，进入直接回收(direct reclaim)，分配者同步等待页面回收——这会导致分配延迟暴涨。

关键水位参数：

• free_high：页面充足，kswapd休眠
• free_low：唤醒kswapd开始回收
• free_min：触发直接回收和OOM-killer

4.3 OOM-Killer的罪与罚

当内存耗尽且回收无效时，OOM-killer通过oom_badness()评分选择杀进程：

long oom_badness(struct task_struct *p, long totalpages) {
    long points = get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS);
    points <<= 10; // MB转得分（越大越该杀）
    points *= 1000 / totalpages; // 按系统内存归一化
    points /= (adj * adj + 1);   // oom_score_adj衰减
    return points; // >600典型的"任务结束者"
}

• Long-running daemon、高RSS用户、非root进程得分倾向较高
• oom_score_adj允许手动保护关键进程（设为-1000永不被杀）
• cgroup v2的memory.max可彻底避免OOM

五、实战调优与观测

5.1 Buddy系统碎片监控

cat /proc/buddyinfo
# Node 0, zone   Normal  12  45 78 123 89 60 30 20 10 5 2 1
# 表示 4KB页有12个空闲、8KB页45个...8MB页1个
# 若order≥3(16KB)的空闲页浓度不足，说明外碎片严重

5.2 SLABTop实时对象跟踪

slabtop -d 1
# OBJS    ACTIVE   USE  OBJ SIZE  SLABS  OBJ/SLAB  CACHE_SIZE  NAME
# 184320  184320  100%    0.19K   1440      128      360MB  dentry
#  81048   66793   82%    0.59K    623      130       48MB  inode_cache
#   1452    1328   91%    1.94K     726      2        5MB  task_struct

5.3 关键参数调优

# 减少直接回收的概率
vm.min_free_kbytes = 262144    # 256MB保留应急储备

# 控制脏页刷新策略
vm.dirty_ratio = 30            # 脏页到达30%强制writeback
vm.dirty_background_ratio = 10 # 后台异步刷新阈值
vm.dirty_expire_centisecs = 3000 # 30秒过期脏页

# NUMA访问策略
/sys/devices/system/node/node0/meminfo
/sys/kernel/mm/numa_zonelist_order=node  # 优先本地节点回退

5.4 BPF Trace用于分配延迟剖析

# trace分配延迟分布
bpftrace -e '
kprobe:__alloc_pages_nodemask {
    @start[tid] = nsecs;
}
kretprobe:__alloc_pages_nodemask /@start[tid]/ {
    @us = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}'

六、前沿趋势

• Memory Folios：Linux 5.16+引入，将复合页抽象为folio结构，扩展THP透明大页支持，减少子页遍历开销
• Cgroup v2 Memory Controller：统一层级、限制递归、PSI压力停滞信息，实现QoS可控的内存隔离
• MGLRU：Multi-Gen LRU用年代分层替代active/inactive双链表，提升非活跃扫描精度，Google实测缓存命中率提升15%
• HBM/CXL内存分层：内核开始感知不同层级内存延迟与带宽，自动迁移热页至HBM

结语

Linux内核内存管理是一个在微观延迟、宏观效率之间不断精妙的平衡系统。伙伴系统以简克繁，将物理页管理抽象为空序链表；SLUB以快打慢，用CPU本地队列换NUMA远程访问；LRU似水流年，用访问时序换来缓存生命力。理解这些机制，不仅是操作系统学习的必修课，更是系统调优、故障排查的必备武器。

在这个内存以TB计的云计算时代，内核炼金术仍在持续进化——从folio到大页、从cgroup v1到v2、从kswapd到MGLRU，每一轮迭代都在叩问同一个问题：如何在有限资源下，让内存子系统榨干硬件的每一分潜力。