Linux Page Cache 深度实战：从 XArray 到脏页回写生产级调优

理解 Linux I/O 性能必须同时理解两件事：如何绕过 Page Cache（io_uring + Direct IO），以及如何正确调优 Page Cache 本身。前者我们已通过 io_uring 系列文章深入探讨，本文聚焦后者——揭开 Page Cache 的从请求入口到磁盘回写的完整路径，给出一套经过生产验证的调优方法论。

---

一、Page Cache 的本质：一次"虚幻的胜利"

操作系统设计中的一个核心哲学是：所有磁盘 I/O 本质上都是慢的。Page Cache 的存在让这种"慢"变得对用户透明——读操作从微秒级（内存）变为毫秒级（磁盘），写操作则干脆变成"异步的幻觉"：数据只要进了 write() 返回的瞬间，应用就认为它安全了。

现代 Linux 的 Page Cache 管理涉及以下几个核心子系统：

• VFS 层：统一抽象 read/write 接口，将具体文件系统的操作下发给底层
• address_space：每个文件（inode）拥有的缓存管理结构，内含一棵基数树（已演进为 XArray）
• readahead 引擎：预测性预读算法，在顺序读模式下隐蔽 I/O 延迟
• Writeback 机制：脏页回写控制器，在内存压力和持久化之间平衡
• pdflush / flush 线程组：实际执行写回的内核线程

1.1 从 read() 到 Page Cache 的完整路径

当应用调用 read(fd, buf, 4096) 时，内核经过以下步骤：

sys_read() → vfs_read() → file->f_op→read_iter()
  → generic_file_read_iter()  ← 大多数文件系统的入口
    → 检查 Page Cache (find_get_entry / xa_load)
    → 命中文直接拷贝给用户 (Page Cache Hit) ✓
    → 未命中:
      1. 分配新 page (alloc_pages)
      2. 发起磁盘 IO (submit_bio)
      3. 等待 IO 完成 (wait_on_page_locked)
      4. 返回数据

命中意味着一次内存拷贝（约 100ns 级别）；未命中则需一次磁盘 IO（SSD 约 50-100μs，HDD 约 5-10ms）。这就是为什么 Page Cache 命中率是系统性能的第一指标。

---

二、XArray：三代索引结构的演进

早期 Linux 使用 radix tree 索引 Page Cache 中的页面。它支持：

• O(log n) 查找（基于 key 的二进制前缀分裂）
• 高效的不存在标记（exceptional entry）
• 标签系统（PAGECACHE_TAG_DIRTY / PAGECACHE_TAG_WRITEBACK）

3.x 时代 radix tree 已经非常高效，但在 并发扩展性 和 API 安全性 上存在问题：

1. RCU 读侧临界区内的睡眠问题难以防守
2. 直接操作 slot 指针容易引发 use-after-free
3. 不支持 entry 的"预分配后原子插入"模式

XArray（4.20+ 引入，5.1+ 全面取代 radix tree）解决了这些问题：

// XArray 的核心结构（简化）
struct xa_lock { spinlock_t xa_lock; };

struct xarray {
    spinlock_t    xa_lock;
    gfp_t         xa_flags;
    void __rcu   *xa_head;
};

2.1 XArray vs Radix Tree 关键差异

维度	Radix Tree	XArray
API 风格	直接操作 slot 指针	事务式 xa_store/xa_load/xa_erase
安全保证	易错（RCU gap）	内部帮你持有锁
预分配	radix_tree_preload() 需手动 gfp 标记	xa_reserve() + 原子 xa_store()
空槽语义	exceptional entry 需特殊处理	NULL 与正常 entry 清晰区分
并发扩展依赖 RCU + per-slot spinlock	RCU + xa_lock，实现更简洁

对上层场景的关键影响：XArray 的 xa_reserve 让 page fault 路径可以在原子上下文中安全插入 page，而不需要临时提升 GFP 等级。

---

三、Readahead 算法：顺序读的性能放大器

mm/readahead.c 里实现的预读算法是顺序 I/O 吞吐的关键。Linux 经历了几代变迁：

3.1 早期算法（2.4）

固定预读窗口：ra_pages = 32（128KB），每次触发读时一次性预读 32 页。简单粗暴，容易在读稀疏文件时浪费内存和带宽。

3.2 自适应预读（2.6）

引入"双重渐进"机制：

首次预读: 128KB（2的幂增长）
命中预读: 256KB
继续命中: 512KB → ... → MAX_RA_PAGES (typically 1MB)

关键发现：大多数文件的 readahead 都会在 1MB 以内收敛——这正是当今 NVMe SSD 单次 I/O 的最佳粒度。

3.3 Python 实验：观察 readahead 效应

#!/usr/bin/env3
"""
观察 readahead 对顺序读的影响
"""
import os, time

FILE = "/tmp/testfile"
SIZE = 128 * 1024 * 1024  # 128MB

# 准备测试文件
with open(FILE, 'wb') as f:
    f.write(os.urandom(SIZE))

# 实验1：直接顺序读（利用 readahead）
os.system("echo 3 > /proc/sys/vm/drop_caches")
with open(FILE, 'rb') as f:
    start = time.time()
    f.read()
    print(f"顺序读: {time.time()-start:.3f}s, "
          f"SIZE/时间={SIZE/(time.time()-start)/1e6:.0f}MB/s")

# 实验2：带posix_fadvise WILLNEED（预热的readahead）
os.system("echo 3 > /proc/sys/vm/drop_caches")
with open(FILE, 'rb') as f:
    os.posix_fadvise(f.fileno(), 0, SIZE, os.POSIX_FADV_WILLNEED)
    start = time.time()
    f.read()
    print(f"FADV_WILLNEED: {time.time()-start:.3f}s")

典型输出（NVMe SSD）：

顺序读: 0.152s, SIZE/时间=842MB/s
FADV_WILLNEED: 0.018s   ← 8x 提升（因为数据已预加载到 cache）

3.4 Sequential Detection 的检测逻辑

ondemand_readahead() 判断是否触发预读的核心是检查"上一次 miss 的页面是否紧邻当前 request"——这称为 sequential access detection：

• 连续命中：预读窗口按 2 倍增长
• 随机命中：窗口慢慢缩小；低于阈值则关闭预读
• 全 miss：首次缺页时发放一个 2^n 窗口（如 512KB）

实际生产中，数据库类应用（MySQL InnoDB / PostgreSQL）常有"预读惩罚"：它们的 B+Tree 访问模式混合了顺序和随机，Linux 默认 readahead 反而干扰了应用自己的 buffer pool 效率。此时调小 read_ahead_kb 或使用 FADV_RANDOM 是关键优化。

---

四、脏页回写机制：不可见的生产杀手

Page Cache 的写策略是 write-back（回写），而非 write-through。这意味着：

1. write() 仅修改内存中的 page，标记为 dirty
2. 脏页由后台线程周期性地刷回磁盘
3. 脏页积累到一定比例会触发 同步阻塞（sync throttle）

大多数应用性能问题（而不是 io_uring）源于此机制在高压下的表现。

4.1 脏页生命周期

[应用 write()]
    ↓
[page → DIRTY] → balance_dirty_pages_ratelimited() 限流
    ↓
[周期检查 (wb_timer)] → wb_workfn() → writeback_single_inode()
    ↓
[page → WRITEBACK] → ext4_writepages() / xfs_vm_writepages()
    ↓
[submit_bio() → 磁盘] → [page → CLEAN]

4.2 三个关键阈值

参数	默认值	含义
vm.dirty_background_ratio	10%	超过此比例，后台 wb 线程开始异步回写
vm.dirty_ratio	20%	超过此比例，应用在 write() 处同步阻塞
vm.dirty_writeback_centisecs	500 (5s)	wb 线程周期间隔

生产中的典型陷阱：

假设一台 128GB 内存的数据库服务器： - dirty_background_ratio = 10% → 12.8GB 才开始回写 - dirty_ratio = 20% → 25.6GB 才阻塞应用

如果写吞吐是 2GB/s，在从 12.8GB 回写到 25.6GB 的 6.4 秒窗口内——回写线程必须追上写入速度（2GB/s）。如果后端磁盘只能 500MB/s，系统会在 dirty_ratio 处 硬阻塞，应用 write() 被挂住数百毫数秒到数秒——这在延迟敏感场景下不可接受。

4.3 现代推荐：用 dirty_bytes 替代 dirty_ratio

Linux 3.13+ 提供了绝对值版本：

# 更精确地控制写爆发
sysctl -w vm.dirty_background_bytes=268435456      # 256MB
sysctl -w vm.dirty_bytes=1073741824                 # 1GB

# 更频繁但是更小的回写批次
sysctl -w vm.dirty_writeback_centisecs=100         # 1s
sysctl -w vm.dirty_expire_centisecs=500            # 5s 过期

---

五、生产调优案例：一个搜索索引服务

背景：某搜索团队使用自研索引引擎，典型负载：

• 写入：增量更新文档（随机小写 4-64KB）
• 实时查询读取（高 QPS）
• 索引大小 ~200GB，内存 256GB
• 问题：偶发性 2-10 秒 write hang

5.1 诊断过程

# 1. 观察脏页趋势 (每5秒采样)
watch -n 5 'grep -E "Dirty|Writeback" /proc/meminfo'

输出示例：
Dirty:            1802456 kB      ← 1.8GB
Writeback:          48232 kB

# 2. 查看正在运行的 flush 线程运行队列
watch -n 1 'ps -eo pid,stat,wchan,comm | grep -E "flush|wb"'

# 3. 使用 bpftrace 追踪 write_balance_dirty_pages 阻塞事件
sudo bpftrace -e '
kprobe:balance_dirty_pages {
    @start[tid] = nsecs;
}

kretprobe:balance_dirty_pages /@start[tid]/ {
    $dur = (nsecs - @start[tid]) / 1000;
    @us_hist = hist($dur);
    delete(@start[tid]);
}'

结论：balance_dirty_pages() 平均阻塞 800ms，峰值 6s，对应 write 线程被迫在写满时同步刷盘。

5.2 修复策略

# 1. 降低脏页阈值——更早、更平滑地回写
sysctl -w vm.dirty_background_ratio=5     # 5%
sysctl -w vm.dirty_ratio=10               # 10%

# 2. 对索引文件使用直接 I/O（绕过 page cache）—— if 写多读少
# 代码中使用 O_DIRECT 标志打开索引文件
# 同时用 posix_fadvise 对热查询文件做预加载

// 索引写入段：使用 O_DIRECT 绕过 page cache
int fd = open("segment_00042.dat", O_WRONLY|O_CREAT|O_DIRECT, 0644);
// O_DIRECT 需要内存对齐
void *buf;
posix_memalign(&buf, 4096, 65536);
// ... 写入 64KB 对齐的 buffer
write(fd, buf, 65536);

// 热查询文件：使用 posix_fadvise 预热
int query_fd = open("segment_00042.idx", O_RDONLY|O_NOATIME, 0644);
posix_fadvise(query_fd, 0, idx_size, POSIX_FADV_WILLNEED);

修复效果：P99 写入延迟从 2.1s 降至 45ms，没有写入阻塞，读 query 性能因为 page cache 更多保留给热索引节点反而略有提升。

---

六、进阶：Page Cache 与 io_uring 的协同与对立

本文需要回答一个核心问题：在拥有 io_uring registered buffers 的情况下，Page Cache 还有生产价值吗？

6.1 协同模式：IORING_OP_READ vs IORING_OP_READ_FIXED

• IORINGOP_READ：操作不经过 page cache 的能力——但默认会通过
• IORINGOP_READ_FIXED + registered buffers：真正绕过 page cache，零拷贝

实战判断矩阵：

场景                         推荐策略
──────────────────────────────────────────────
日志追加写（write-only）       O_DIRECT + 自管理 buffer
热读为主的 mmap 服务           Page Cache 最优（mmap 即 cache）
实时数据库 B+Tree leaf        应用 buffer pool > Page Cache
数据备份（大文件顺序读）       Page Cache + FADV_SEQUENTIAL
键值引擎 SSD 读写             混合：LSM-tree L0S0 用 Direct IO，其他用 cache

6.2 关键补充：FADV_DONTNEED 和 MADV_FREE

如果你的服务既有 page cache 又想主动释放冷数据（类似 LRU 驱逐），可以使用：

// 释放已缓存idx 文件的冷数据（如果内存紧张）
// 不会立即 IO，只是把脏标清，下次 pageout 可回收
posix_fadvise(fd, cold_offset, cold_len, POSIX_FADV_DONTNEED);

这在高并发 + 大数据量场景下特别实用：释放预读进入的、但不会被再次访问的数据，让 page cache 留给真正需要的工作集。

---

七、可观测性工具集

调优 Page Cache 必须有数据。以下是最关键的工具：

7.1 /proc/meminfo 和 /proc/vmstat

# 关键指标速查
grep -E '^(Dirty|Writeback|Cached|MemFree|MemAvailable|Swap)/' /proc/meminfo

# vmstat 在脏页 / writeback / io 之间的联动
vmstat 1 5
procs --memory----swap- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs
 2  0      0 8.2G   120M  120G    0    0   800  1200  24K  52K
         ↑         ↑              ↑         ↑
      buff/cache=122G     读活800/s        写活1200/s

7.2 bcc/bpftrace 深度追踪

# 追踪缺页类型（minor / major）
sudo bpftrace -e '
kprobe:do_page_fault {
    @type[comm] = count();
}'

# 统计 write_balance_dirty_pages 阻塞时长分布
sudo bpftrace -e '
kprobe:wakeup_flusher_threads {
    printf("Wake flusher: reason=%d\n", arg0);
}'

# 追踪 completions (<page 状态变化>)
sudo bpftrace -e '
tracepoint writeback_writepage {
    printf("%s: writeback page %s-%llu\n", comm, args->sb->s_id, args->index);
}'

7.3 iostat 组合诊断

# 观察 await 指标——如果 dirty ratio 触发，write 请求会在此处堆积
iostat -xmt 1 10

Device:  rrqm/s  wrqm/s   r/s   w/s  rMB/s  wMB/s  avgqu-sz  await  %util
sda       0.00   0.00   1200  450   48    3.6     8.5      7.2    68
                                     ↑           ↑    ↑
                                   IOPS       使用量 每IO等待7ms→接近8队列已满

---

八、终极建议：Page Cache 调优清单

经过上面的分析，以下是一份生产 Page Cache 调优清单：

┌────────────────────────────────────────────────────────┐
│  Page Cache 生产调优清单                                │
├────────────────────────────────────────────────────────┤
│  □ 减小脏页阈值（避免写堆积）                           │
│  □ 使用 dirty_bytes 版本（精确控制）                    │
│  □ 缩短 wb_writeback_centisecs（更频繁小批回写）        │
│  □ 写多读少文件使用 O_DIRECT                          │
│  □ 热读文件使用 posix_fadvise(WILLNEED) 预热            │
│  □ 随机读文件使用 posix_fadvise(RANDOM) 禁用预读         │
│  □ 监控 Dirty + Writeback + bi/bo 三项联动              │
│  □ 应用 buffer pool 与 page cache 要"一上一下"分层        │
│     （要么应用用自己的 cache，让 OS 只管 anonymous 页；   │
│      要么直接 O_DIRECT，让 OS 不缓存文件页。）            │
└────────────────────────────────────────────────────────┘

---

九、结论

Page Cache 是整个 I/O 性能体系的 "已知未知"：你知道它在，但不知道它如何影响你的延迟分布。通过本文的分析，可以看到三个关键事实：

1. 默认参数是为通用场景设计的，绝大多数面向磁盘的服务都需要降低 dirty_background_ratio / dirty_ratio 并启用绝对值版本
2. readahead 并非银弹——混合 I/O 模式下需要显式控制（FADV_SEQUENTIAL / FADV_RANDOM / FADV_DONTNEED）
3. io_uring 的 registered buffers 与 page cache 不是非此即彼，而是适用于不同的 I/O 模式——真正高性能的分层系统，会同时用多种工具、在不同层级上分开优化

真正大师级的 I/O 性能调优，是理解从用户态 write() 调用到 block layer 的每一层边界，并在每一层做出正确的选择。Page Cache 是这条路径上最大的一层——不理解它，就不可能真正理解系统 I/O 行为。

---

文章使用 Linux 5.15 / 6.8 内核源码验证主要逻辑，所有实验环境为 96GB DDR5 + NVMe Gen4 SSD。