Linux 性能实战 | 第 13 篇 虚拟内存与分页机制深度解析

Linux 性能实战 | 第 13 篇｜虚拟内存与分页机制深度解析 🗺️

🔗 从内核对象到进程地址空间：内存管理的另一面

在第十二章中，我们深入探讨了 Linux 内核如何管理自己的内存------通过 Slab/SLUB 分配器高效地分配和回收内核对象（dentry、inode、task_struct 等）。我们还诊断了一个激光雷达驱动的内存泄漏问题，成功将不可回收 Slab 内存从 2.6GB 降至 245MB。

但是，用户态程序 （如自动驾驶的感知算法、路径规划模块）使用的是完全不同的内存管理机制------虚拟内存 。当我们在 C++ 代码中执行 new 或 malloc() 时，操作系统并不会立即分配物理内存，而是给程序一个"承诺"：这块虚拟地址将来可以使用。只有在程序真正访问这块内存时，才会触发 Page Fault，此时内核才分配物理页并建立映射。

本章关键问题：

• 为什么需要虚拟内存？直接使用物理地址不行吗？
• 页表如何将 48 位虚拟地址转换为物理地址？
• Page Fault 为什么会导致性能下降？
• Copy-on-Write 如何让进程 fork 变得极快？

---

🤔 虚拟内存的三大设计目标

1. 隔离（Isolation）：进程之间互不干扰

没有虚拟内存的世界（早期计算机）：

• 所有程序直接访问物理地址
• 程序 A 的 bug 可能覆盖程序 B 的数据
• 一个程序崩溃可能导致整个系统崩溃

虚拟内存的隔离：
物理内存的现实
进程 B 的视角
进程 A 的视角
页表 A
页表 B
虚拟地址空间

0x00000000 - 0x7FFFFFFFFFFF

看到的是 '独占' 整个内存
虚拟地址空间

0x00000000 - 0x7FFFFFFFFFFF

同样看到 '独占' 整个内存
物理内存

实际只有 32GB

通过页表映射

进程 A 和 B 互不干扰

自动驾驶示例：

• 感知进程 使用虚拟地址 0x7f8a12340000 存放点云数据
• 规划进程 也可以使用 0x7f8a12340000 存放路径数据
• 两者互不冲突，因为它们映射到不同的物理页

2. 保护（Protection）：防止非法访问

虚拟内存为每个页设置权限位：

• R (Read)：可读
• W (Write)：可写
• X (Execute)：可执行
• U (User)：用户态可访问

// 自动驾驶代码段（只读+可执行）
void ProcessLidarData() {
    // 代码页的权限：R-X（可读+可执行，不可写）
    // 尝试修改代码会触发 Segmentation Fault
}

// 只读数据段（只读）
const float kLidarMaxRange = 150.0;  // R--（只读）

// 可读写数据段
std::vector<Point> point_cloud;  // RW-（可读+可写）

访问控制：

• 如果程序尝试写入只读页 → Page Fault → 内核终止进程（Segmentation Fault）
• 如果程序尝试执行数据页 → Page Fault → 内核终止进程（防止代码注入攻击）

3. 共享（Sharing）：高效利用内存

共享库（Shared Libraries）：
物理内存
只读映射
只读映射
只读映射
只读映射
只读映射
libc.so.6

标准 C 库

物理内存只有一份
libopencv.so

OpenCV 库

物理内存只有一份
感知进程

虚拟地址 0x7f1234000000

映射到 libc.so.6
规划进程

虚拟地址 0x7f5678000000

映射到 libc.so.6
控制进程

虚拟地址 0x7f9abc000000

映射到 libc.so.6

节省内存：

• libc.so.6 约 2MB，如果 10 个进程各自加载一份 → 20MB
• 虚拟内存共享机制 → 物理内存只有一份 → 2MB

---

🗺️ 页表：虚拟地址到物理地址的"地图"

1. 单级页表的问题

假设使用 4KB 页大小 ，64 位虚拟地址空间（实际使用 48 位）：

单级页表需要的内存：

虚拟地址空间大小：2^48 = 256TB
页大小：4KB = 2^12
页表项数量：256TB / 4KB = 2^36 = 64G 个页表项
每个页表项大小：8 字节
页表总大小：64G × 8 = 512GB  ⬅️ 每个进程需要 512GB 页表！

问题：一个进程的页表就需要 512GB 内存，显然不可行。

2. 多级页表（4 级页表）

Linux 使用 4 级页表 将 512GB 的页表拆分成小块，按需分配：
虚拟地址

48 位

0x7f8a12340000
PGD

页全局目录

9 位索引
PUD

页上级目录

9 位索引
PMD

页中级目录

9 位索引
PTE

页表项

9 位索引
页内偏移

12 位
物理地址

0x1a2b3c4000

地址分解（48 位虚拟地址）：

虚拟地址：0x00007f8a12340567
         ├─ PGD 索引：位 [47:39]（9 位） = 0x0FE
         ├─ PUD 索引：位 [38:30]（9 位） = 0x144
         ├─ PMD 索引：位 [29:21]（9 位） = 0x091
         ├─ PTE 索引：位 [20:12]（9 位） = 0x034
         └─ 页内偏移：位 [11:0]（12 位） = 0x567

内存节省原理：

• 如果一个虚拟地址范围没有被使用，对应的 PUD/PMD/PTE 根本不会被分配
• 一个典型的进程只使用了虚拟地址空间的极小部分（< 1%）
• 实际页表大小：几 MB 而非 512GB

3. TLB：地址转换的"缓存"

页表查询的开销：

• 每次内存访问都需要查 4 级页表 → 5 次内存访问（4 次查表 + 1 次读数据）
• 如果每次都这样，程序速度会降低 5 倍！

TLB (Translation Lookaside Buffer) 是硬件缓存，存储最近使用的"虚拟地址 → 物理地址"映射：
物理内存 页表（内存） TLB CPU 物理内存 页表（内存） TLB CPU alt [TLB 命中] [TLB 未命中] 查询虚拟地址 0x7f8a12340567 返回物理地址 0x1a2b3c4567（快速 ~1ns） 访问物理地址 返回数据 查询 PGD 查询 PUD 查询 PMD 查询 PTE 返回物理地址（慢 ~100ns） 更新 TLB 缓存 返回物理地址 访问物理地址 返回数据

TLB 参数（Intel CPU）：

• 容量：L1 TLB ~64 项，L2 TLB ~1024 项
• 覆盖范围：64 × 4KB = 256KB（L1 TLB）
• 命中率：通常 > 95%

自动驾驶场景中的 TLB 问题：

• 大型点云数据（300,000 点 × 16 字节 = 4.8MB）跨越 1200 个页
• 如果随机访问，TLB 无法缓存所有页表项 → 频繁 TLB Miss → 性能下降 20-30%

---

💥 Page Fault：虚拟内存的"延迟加载"机制

1. Page Fault 的触发条件

当 CPU 访问一个虚拟地址时，如果页表中对应的 Present 位 = 0 （页不在物理内存中），就会触发 Page Fault。

Page Fault 的处理流程：
是
否
是，页在 Swap
是，页未分配
否，非法地址
CPU 访问虚拟地址
页表 Present 位 = 1?
直接访问物理内存
触发 Page Fault 中断
页表项存在但

Present=0?
Major Fault

从磁盘加载页

耗时 ~10ms
Minor Fault

分配物理页

耗时 ~1μs
Segmentation Fault

终止进程
更新页表

Present=1

2. Minor Fault vs Major Fault

类型	触发条件	处理方式	延迟	影响
Minor Fault	页表项未分配 或 COW（写时复制）	分配物理页 或复制页	~1-10 μs	轻微
Major Fault	页被 swap 到磁盘 或 mmap 文件未加载	从磁盘读取页	~1-10 ms	严重（慢 1000 倍）

查看进程的 Page Fault 统计：

# 查看进程的详细内存统计
cat /proc/<PID>/status | grep -E "VmPeak|VmSize|VmRSS|VmSwap"

# 查看 Page Fault 次数
ps -o min_flt,maj_flt,cmd -p <PID>

输出示例：

  MINFL  MAJFL CMD
2345678    123 /usr/bin/perception_node

• MINFL（Minor Fault）：2,345,678 次
• MAJFL（Major Fault）：123 次

解读：

• Minor Fault 很多是正常的（Demand Paging、COW）
• Major Fault 较多说明进程使用了 Swap 或频繁访问 mmap 的文件

3. Demand Paging：按需分配的智慧

传统方式（Eager Loading）：

// 分配 1GB 内存
void *buffer = malloc(1GB);
// 操作系统立即分配 1GB 物理内存，即使程序可能只用 10MB

Demand Paging（按需分配）：

void *buffer = malloc(1GB);
// 操作系统只记录：虚拟地址 [X, X+1GB) 可用
// 物理内存未分配

buffer[0] = 42;  // ⬅️ 首次访问，触发 Minor Fault，分配第一个 4KB 页
buffer[4096] = 99;  // ⬅️ 访问第二个页，触发 Minor Fault，分配第二个页
// 只分配了 8KB 物理内存，而非 1GB

优势：

• 节省内存：只分配实际使用的页
• 加快启动：程序无需等待所有内存分配完成

自动驾驶示例：

// 预分配点云缓冲区（最大 100 万点）
std::vector<Point> point_cloud;
point_cloud.reserve(1'000'000);  // 虚拟地址预留 16MB

// 实际只收到 30 万点
for (int i = 0; i < 300'000; ++i) {
    point_cloud.push_back(lidar_points[i]);  // 只分配 4.8MB 物理内存
}
// 节省了 11.2MB 内存

---

🐄 Copy-on-Write：让 fork 变得极快

1. fork 的传统实现

没有 COW 的 fork：

pid_t child_pid = fork();  // 创建子进程

// 传统方式：
// 1. 复制父进程的所有内存（如 2GB）到子进程
// 2. 耗时：2GB / 1GB/s = 2 秒

问题：

• fork 后子进程通常立即调用 exec() 加载新程序
• 复制的 2GB 内存完全浪费（立即被丢弃）

2. Copy-on-Write 优化

COW 的 fork：
子进程写入时
触发 Page Fault
子进程

尝试写入
COW 处理

1. 复制页

2. 更新页表
   子进程的私有页

可读写
父进程的原始页

可读写
fork 之后（COW）
只读映射
只读映射
父进程

虚拟地址空间
共享物理页

标记为只读
子进程

虚拟地址空间

COW 流程：

1. fork 时 ：子进程共享父进程的所有物理页，页表标记为只读
2. 读取时：父子进程都直接读取共享页，无开销
3. 写入时 ：触发 Page Fault → 内核复制该页 → 子进程获得私有副本

性能对比：

操作	传统 fork	COW fork
fork 耗时	2GB / 1GB/s = 2 秒	复制页表 = < 1ms
内存占用	父进程 2GB + 子进程 2GB = 4GB	父子共享 2GB = 2GB

自动驾驶示例：

// 主进程加载高精地图（2GB）
LoadHDMap("/mnt/maps/city_map.bin");

// 创建多个感知进程
for (int i = 0; i < 4; ++i) {
    if (fork() == 0) {
        // 子进程：只读访问地图数据（共享）
        ProcessSensorData(sensor_id = i);
        exit(0);
    }
}

// 内存占用：2GB（地图） + 4 × 200MB（各进程的私有数据） = 2.8GB
// 如果没有 COW：2GB × 5 = 10GB

---

🛠️ 实战案例：诊断 Major Fault 导致的性能下降

1. 问题现象

一个自动驾驶数据回放系统，回放 rosbag 文件时，处理帧率从预期的 30 fps 下降到 5 fps。

初步检查：

top

输出：

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
12345 user      20   0  12.5g   2.3g   1.2g D  95.0  7.2   5:23.45 rosbag_player

异常点：

• CPU 使用率 95%，但帧率只有 5 fps（应该能达到 30 fps）
• 进程状态 D（不可中断睡眠）→ 等待 I/O
• VIRT 12.5GB，但 RES 只有 2.3GB → 大量虚拟内存未加载

怀疑：频繁的 Major Fault 导致性能下降

2. 使用 vmstat 诊断

vmstat 1

输出：

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  1      0 5234M  123M  18.2G    0    0  8456  234  567 1234 15 10 65 10  0
 1  1      0 5123M  123M  18.3G    0    0  8923  189  589 1289 12  8 70 10  0
 1  1      0 5056M  123M  18.4G    0    0  9234  201  601 1345 14  9 67 10  0

关键指标：

• bi (block in)：8456 KB/s，从磁盘读取数据速率很高
• wa (iowait)：10%，CPU 等待 I/O

进一步检查 Page Fault：

# 持续监控进程的 Page Fault
watch -n 1 "ps -o min_flt,maj_flt,cmd -p 12345"

输出：

  MINFL  MAJFL CMD
3456789  12345 /usr/bin/rosbag_player  ⬅️ Major Fault 持续增长！

# 1 秒后
  MINFL  MAJFL CMD
3457890  12890 /usr/bin/rosbag_player  ⬅️ 增加了 545 次 Major Fault！

每秒 545 次 Major Fault，每次耗时约 2ms → 每秒浪费 545 × 2ms = 1.09 秒 → 吞吐量下降到 1/1.09 ≈ 0.92 → 帧率从 30 fps 降至 5 fps！

3. 根因分析

检查进程的内存映射：

cat /proc/12345/maps | grep rosbag

输出：

7f8a00000000-7f8b00000000 r--s 00000000 08:02 1234567  /mnt/data/huge_dataset.bag  ⬅️ 16GB 文件

根因：

• rosbag_player 使用 mmap() 映射了一个 16GB 的 bag 文件
• 物理内存只有 32GB，无法一次性加载整个文件
• 每次访问新的数据块时，触发 Major Fault → 从 SSD 读取 → 延迟 ~2ms

4. 优化方案

方案 1：使用 madvise() 预取

// 原始代码（随机访问，频繁 Major Fault）
void *data = mmap(nullptr, file_size, PROT_READ, MAP_PRIVATE, fd, 0);

// 优化后（顺序预取，减少 Major Fault）
void *data = mmap(nullptr, file_size, PROT_READ, MAP_PRIVATE, fd, 0);

// 建议内核：顺序访问，主动预读
madvise(data, file_size, MADV_SEQUENTIAL);

// 建议内核：预读接下来的 100MB
madvise(data + current_offset, 100MB, MADV_WILLNEED);

方案 2：使用 MAP_POPULATE 预加载

// 在 mmap 时预加载数据到物理内存（适合文件较小）
void *data = mmap(nullptr, file_size, PROT_READ, 
                  MAP_PRIVATE | MAP_POPULATE, fd, 0);
// 注意：MAP_POPULATE 会阻塞直到文件加载完成

方案 3：分块读取

// 不使用 mmap，使用传统的 read() 分块读取
std::vector<char> buffer(4MB);
while (true) {
    ssize_t n = read(fd, buffer.data(), buffer.size());
    if (n <= 0) break;
    ProcessData(buffer.data(), n);
}
// 避免 Major Fault，但需要额外的数据拷贝

5. 优化效果

实施方案 1 后：

vmstat 1

优化后：

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 4123M  123M  19.8G    0    0  1234   89  234  456 75 15  8  2  0
 2  0      0 4089M  123M  19.9G    0    0  1189   92  245  478 78 12  9  1  0

改善：

• bi：从 8456 KB/s 降至 1234 KB/s（减少 85%）
• wa：从 10% 降至 2%（减少 80%）

Page Fault 统计：

ps -o min_flt,maj_flt,cmd -p 12345

  MINFL  MAJFL CMD
4567890     45 /usr/bin/rosbag_player  ⬅️ Major Fault 从 545/s 降至 ~5/s

帧率恢复：5 fps → 28 fps（接近目标 30 fps）

---

🐘 透明大页（THP）：性能提升还是陷阱？

1. 大页的优势

**标准页（4KB）**的问题：

• TLB 容量有限（64-1024 项）
• 大型数据集（如 1GB 点云）需要 256,000 个页表项
• TLB 无法缓存 → 频繁 TLB Miss → 性能下降 20-30%

**大页（2MB 或 1GB）**的优势：

• 1GB 数据只需 512 个 2MB 页，或 1 个 1GB 页
• TLB 覆盖范围扩大 512 倍
• 减少 TLB Miss，提升性能 10-30%

2. 透明大页（THP）的工作原理

传统大页（Huge Pages）：

• 需要手动配置（/proc/sys/vm/nr_hugepages）
• 应用程序需要使用特殊 API（mmap + MAP_HUGETLB）

透明大页（THP）：

• 内核自动将连续的小页合并为大页
• 应用程序无需修改代码
• Linux 2.6.38+ 默认启用

查看 THP 状态：

cat /sys/kernel/mm/transparent_hugepage/enabled

输出：

always [madvise] never

• always：总是尝试使用大页
• madvise：只在应用程序使用 madvise(MADV_HUGEPAGE) 时使用
• never：禁用 THP

3. THP 的陷阱

问题 1：内存碎片导致分配延迟

• 合并大页需要 512 个连续的 4KB 页（2MB 页）
• 如果内存碎片化严重，合并失败 → 触发内存整理（compaction）→ 延迟 10-100ms

问题 2：不适合频繁分配/释放的场景

// 数据库场景（频繁分配/释放小对象）
for (int i = 0; i < 1000000; ++i) {
    void *ptr = malloc(4KB);  // THP 尝试分配 2MB 大页
    // 使用 ptr
    free(ptr);  // 释放，但大页可能无法立即回收
}
// 结果：内存占用飙升，性能下降

问题 3：Swap 性能下降

• 4KB 页 swap out：只需写入 4KB
• 2MB 大页 swap out：需要写入 2MB → 慢 512 倍

4. 自动驾驶场景中的 THP 策略

推荐使用 THP 的场景：

• 点云处理 ：大块连续内存，长时间使用

  std::vector<Point> point_cloud(1'000'000);  // 16MB 连续内存
  // THP 可以将其映射为 8 个 2MB 大页，减少 TLB Miss

不推荐使用 THP 的场景：

• 频繁分配/释放小对象：如目标检测中的 bounding box
• 内存受限的嵌入式系统：THP 可能导致内存碎片

配置建议：

# 对于自动驾驶计算平台，推荐使用 madvise 模式
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

# 在代码中显式启用 THP
void *point_cloud_buffer = malloc(16MB);
madvise(point_cloud_buffer, 16MB, MADV_HUGEPAGE);

---

📝 总结与最佳实践

核心要点

• 虚拟内存提供隔离、保护、共享：让进程安全、高效地使用内存
• 多级页表 + TLB：平衡了页表大小和地址转换速度
• Page Fault 分两类 ：
  • Minor Fault（~1μs）：正常的 Demand Paging、COW
  • Major Fault（~1ms）：从磁盘读取，性能杀手
• Copy-on-Write 让 fork 极快：从秒级优化到毫秒级
• mmap 提供高效的文件访问：但需要注意 Major Fault
• THP 是双刃剑：大数据集受益，频繁分配/释放受害

虚拟内存诊断清单

✅ 监控 Page Fault

# 实时监控进程的 Page Fault
watch -n 1 "ps -o min_flt,maj_flt,cmd -p <PID>"

# 查看系统级 Page Fault
vmstat 1

# 查看进程内存详情
cat /proc/<PID>/status | grep -E "VmPeak|VmSize|VmRSS|VmSwap"

✅ 优化 Major Fault

# 使用 madvise 优化 mmap
madvise(ptr, size, MADV_SEQUENTIAL);  # 顺序访问
madvise(ptr, size, MADV_WILLNEED);    # 预读数据

# 监控磁盘 I/O
iostat -x 1

✅ TLB 优化

# 查看 TLB 性能
perf stat -e dTLB-load-misses,dTLB-loads ./my_program

# 启用 THP（适合大数据集）
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

自动驾驶系统内存优化建议

场景	问题	优化方案
点云处理	大数据集，TLB Miss 多	启用 THP，使用 madvise(MADV_HUGEPAGE)
高精地图加载	mmap 大文件，Major Fault 多	madvise(MADV_SEQUENTIAL) 预读
多进程感知	fork 慢，内存占用高	利用 COW，只读共享数据
实时控制	Page Fault 导致延迟抖动	mlockall() 锁定内存，禁止 swap

实时系统关键配置：

// 锁定所有内存，防止 Page Fault 导致的延迟
#include <sys/mman.h>

int main() {
    // 锁定当前和未来的所有内存
    if (mlockall(MCL_CURRENT | MCL_FUTURE) != 0) {
        perror("mlockall failed");
        return 1;
    }
    
    // 实时控制逻辑（无 Page Fault）
    RunRealtimeControl();
    
    munlockall();
    return 0;
}

---

🎯 下一章预告

在本章中，我们深入理解了虚拟内存的三大设计目标------隔离、保护、共享，掌握了多级页表和 TLB 的工作原理，学会了诊断 Major Fault 导致的性能问题，并探讨了 Copy-on-Write 和透明大页的优化技术。

在下一章《Swap 使用分析与优化策略》中，我们将探索系统内存不足时的"救命稻草"：

• Swap 的真正作用：不仅仅是"内存不足时的备胎"
• swappiness 参数的真实含义：为什么不是 60 就开始 swap
• swap in/out 的性能影响：如何诊断 swap 导致的系统变慢
• Zswap 和 zRAM：内存压缩技术的性能提升
• 何时应该禁用 swap：数据库、实时系统的最佳实践

通过真实的自动驾驶场景案例，我们将揭示 swap 机制对系统性能的深远影响。敬请期待！🚀