Linux内存管理：虚拟地址空间与物理内存分配机制

1. 虚拟地址空间：用户与内核的隔离屏障

现代操作系统最精妙的设计之一，就是让每个进程都"自以为"独占了整个内存空间。在32位系统上，每个进程看到的都是0x00000000到0xFFFFFFFF的连续地址范围，而实际上物理内存可能只有1GB。这种魔法般的体验，全靠虚拟地址空间机制实现。

1.1 地址空间布局的艺术

Linux采用经典的3:1内存划分——用户空间占3GB（0x00000000-0xBFFFFFFF），内核空间占1GB（0xC0000000-0xFFFFFFFF）。这个划分在include/asm-generic/memory_model.h中通过PAGE_OFFSET常量定义。实际布局中包含着多个关键区域：

• 用户栈：从0xBFFFFFFF向低地址增长，默认最大8MB
• 内存映射区：装载共享库和mmap文件
• 堆空间：通过brk/sbrk系统调用扩展
• 数据段：存储全局变量和静态变量
• 代码段：存放可执行指令

内核空间则包含直接映射区（896MB）、vmalloc区、固定映射区等。这种设计使得用户程序无法直接访问内核数据，而内核通过页表可以访问全部内存空间。

提示：在64位系统上，地址空间变得极其庞大（48位可用地址空间为256TB），因此内核采用了全新的内存布局方式，用户和内核空间的比例也不再是3:1。

1.2 页表：虚拟到物理的翻译官

当程序访问0x12345678这个地址时，CPU会通过MMU查询页表进行地址转换。Linux采用四级页表结构（PGD→P4D→PUD→PMD→PTE），在arch/x86/include/asm/pgtable_64.h中定义。每个页表项不仅包含物理地址，还包含权限位：

code复制63      62      61      60      59      58-52   51-12    11-0
NX位  保留位  PKRU位 全局位  PAT位  忽略位   物理地址  标志位

标志位包括：

• _PAGE_PRESENT：页面是否存在
• _PAGE_RW：是否可写
• _PAGE_USER：用户空间是否可访问
• _PAGE_ACCESSED：是否被访问过
• _PAGE_DIRTY：页面是否被修改

地址转换过程会触发TLB查找、页表遍历等操作，这些都是性能敏感路径。内核开发者常使用perf工具监控TLB命中率：

bash复制perf stat -e dTLB-load-misses,dTLB-store-misses <command>

2. 伙伴系统：物理内存的管理大师

虚拟地址最终要落实到物理内存上，而物理内存的管理是内核最复杂的任务之一。伙伴系统（Buddy System）解决了外部碎片问题，其核心思想可以用"分合之道"来概括。

2.1 分配器的工作原理

伙伴系统将物理内存划分为多个阶（order）的块，每个阶包含2^order个连续页面。在mm/page_alloc.c中，free_area数组管理着不同阶的空闲块：

c复制struct free_area {
    struct list_head free_list[MIGRATE_TYPES];
    unsigned long nr_free;
};

当申请4个页面时：

1. 检查order=2的free_list是否有空闲块
2. 如果没有，向上查找order=3的列表，分割为两个order=2的块
3. 其中一个用于分配，另一个加入order=2的free_list

释放内存时，系统会检查相邻的"伙伴"块是否空闲，如果是就合并成更高阶的块。这种设计保证了任意时刻内存都能被拆分为大小合适的块。

2.2 迁移类型与反碎片

现代内核引入了迁移类型（MIGRATE_TYPES）来减少碎片：

• MIGRATE_UNMOVABLE：内核核心数据等不可移动页面
• MIGRATE_RECLAIMABLE：可回收页面
• MIGRATE_MOVABLE：用户空间页面等可移动内存
• MIGRATE_CMA：连续内存分配器专用区域

通过/proc/buddyinfo可以查看当前内存状态：

code复制Node 0, zone   Normal   11    8    5    3    2    1    1    0    0    0    0

这表示order0有11个空闲块，order1有8个，以此类推。当高阶数字持续为0时，说明内存碎片化严重。

3. 块分配器：小内存的高效管家

伙伴系统最小分配单位是页（通常4KB），但内核常需要分配几十字节的小对象。slab分配器（包括后来的slub、slob变种）应运而生，专门管理内核中的小型对象分配。

3.1 slab的核心设计

每个slab缓存管理特定类型的对象，如task_struct、inode等。主要结构体包括：

• kmem_cache：描述一个缓存类型
• kmem_cache_node：每个NUMA节点的管理数据
• slab_page：描述单个slab页面

查看系统所有slab缓存：

bash复制cat /proc/slabinfo

输出示例：

code复制dentry            99204  99204    192   21    1 : tunables    0    0    0 : slabdata   4724   4724      0

表示dentry对象大小192字节，每个slab页容纳21个对象，当前活跃99204个对象。

3.2 调试与优化技巧

内存泄漏是内核开发常见问题，几个实用工具：

1. kmemleak：检测可能的内存泄漏

bash复制echo scan > /sys/kernel/debug/kmemleak

2. slabtop：实时查看slab使用情况
3. /proc/meminfo中的Slab/SReclaimable/SUnreclaim字段

优化建议：

• 高频使用的小对象应创建专用slab缓存
• 合理设置构造函数和析构函数
• 注意NUMA本地化分配，使用kmem_cache_alloc_node()

4. 实战：从malloc到物理页的完整旅程

当用户程序调用malloc(1024)时，背后发生了这些关键步骤：

1. glibc内存分配器检查tcache/fastbins是否有合适块
2. 没有则通过brk或mmap扩展堆空间（触发系统调用）
3. 内核的vm_area_struct管理用户进程地址空间
4. 缺页异常触发物理页分配（可能触发OOM killer）
5. 伙伴系统从适当迁移类型的free_area获取页面
6. 页表项被更新，建立虚拟到物理的映射

可以通过ftrace跟踪这个流程：

bash复制echo function_graph > /sys/kernel/debug/tracing/current_tracer
echo "SyS_brk" > /sys/kernel/debug/tracing/set_grahp_function
cat /sys/kernel/debug/tracing/trace_pipe

在内存紧张时，内核会触发回收机制：

• 直接内存回收（同步过程，可能导致延迟）
• kswapd后台回收（异步）
• OOM killer选择进程终止

理解这些机制对系统调优至关重要。例如，调整vm.swappiness可以改变回收倾向：

bash复制sysctl -w vm.swappiness=60

通过十多年的内核开发经验，我发现内存管理最易出问题的是边界条件处理——比如高端内存与DMA区域的交互、NUMA架构下的跨节点访问等。建议在开发内核模块时，始终使用GFP标志明确指定内存类型和分配策略，避免使用简单的GFP_KERNEL。同时，对于性能敏感路径，可以考虑使用内存池技术预分配关键对象。