Page Cache总览

理解存储系统时，Page Cache 最容易被误看成一个“读写加速器”，仿佛它的作用只是把磁盘前面垫上一层内存。但如果把它仅仅理解成缓存，就会错过它在整个 I/O 体系中的真实位置。它不是附着在文件系统旁边的一个可有可无的优化件，而是 Linux 通用文件 I/O 路径里的核心组织层。应用发出的 read 和 write 并不是直接与块设备对话，而是先进入由页为单位管理的内核状态空间；从这一刻起，文件数据不再只是“磁盘上的内容”，而开始同时以缓存状态、脏页状态、回写状态和回收状态存在于内核的调度逻辑里。也正因为如此，Page Cache 连接的从来不只是性能问题，它同时决定了可见性、一致性、内存压力传播方式，以及后续 fsync、日志提交和崩溃恢复究竟在和什么打交道。

如果顺着一条读路径往下看，Page Cache 的角色相对直观。应用调用 read 之后，内核首先关心的不是设备能不能立刻给出数据，而是目标数据对应的页是否已经处在缓存里。如果命中，数据直接从内存复制回用户态，这条请求在逻辑上完成得很快，因为它根本没有进入慢速设备路径。如果未命中，内核才会把缺失的页组织成底层 I/O 请求，等待设备把内容带回，再把这些页纳入缓存管理。于是一次“磁盘读”真正落到设备上的前提，不是应用做了读调用，而是系统判断当前缓存状态无法满足这次访问。这就是为什么很多文件系统工作负载的性能曲线，首先受缓存命中率支配，而不是直接受介质带宽支配。应用看到的是读延迟，内核面对的却是一个不断变化的“页是否已经在场”的状态判断问题。

写路径的建模价值更大，因为它直接决定了很多人最容易混淆的语义边界。应用调用 write 时，内核通常不会把这次修改同步地一路推到底层设备，而是先把数据复制进缓存页，把相关页标记为脏页，再把这次修改纳入后续回写机制。也就是说，write 返回成功时，最常见的事实并不是“数据已经落盘”，而是“内核已经接管这次修改，并承诺后续会在某个时机推进它”。这一步把一次物理写操作改造成了一次状态登记：文件内容的最新版本先存在于内存里的页状态中，设备上的旧版本暂时仍然存在，只是已经不再代表系统逻辑上最新的视图。正是这一层状态分离，使 Page Cache 成为高吞吐的基础，也使它成为持久化语义最常见的误解来源。

从机制上说，Page Cache 真正解决的是速度失配和请求形状失配。速度失配指的是 CPU 与内存远快于块设备，应用如果每次写一点都同步等待真实介质完成，系统很快就会被同步等待拖住。请求形状失配指的是应用侧常常产生零碎、小块、短时突发且缺乏顺序性的访问，而设备更偏好更大、更连续、更可合并的 I/O。Page Cache 通过把大量瞬时请求吸收到内存中，把原本零碎的用户态动作重写成一个可调度、可延后、可合并的内核工作集，从而把性能问题从“每次调用都必须立刻打到设备”改造成“系统如何批量地、择机地把脏页推出去”。这就是它能显著提高平均吞吐的根本原因。很多时候，应用的快并不是因为磁盘突然变快了，而是因为应用已经不再和磁盘保持同一节奏。

但只要接受了这种节奏解耦，就必须同时接受它带来的状态复杂性。Page Cache 中最关键的概念不是“页被缓存了”，而是“页处在什么状态”。干净页意味着它与底层存储内容一致，可以被回收、可以被再次命中；脏页意味着内核里存在尚未对底层介质完成的更新，这些页一方面代表了系统逻辑上的最新数据，另一方面又构成了未来必须被推进的债务。于是写入一旦发生，系统内部就不再只有“有没有数据”这个问题，而变成“哪些页脏了、脏了多久、积累到了什么程度、是否该回写、回写是否受阻、受阻后是否反压上游写入、若内存紧张应优先回收哪些页”。从这个意义上说，Page Cache 并不是静态容器，而是一套围绕页状态不断做判断和调度的控制系统。

回写就是这套控制系统里最重要的推进机制。脏页不会永久停留在内存里，否则系统既无法提供真实持久化，也无法承受无限制积累的内存债务。内核因此需要在若干条件满足时把脏页向下推进：有时是脏页占比上升，系统觉得继续积累会让后续成本过高；有时是周期性回写线程到点，系统希望把长期悬而未决的修改往下清；有时是内存压力变大，回收干净页之前必须先把部分脏页转成可回收状态；还有时是应用显式调用 fsync、fdatasync 或其他同步接口，主动要求把一部分状态越过提交边界。这里最值得把握的，不是某一个内核线程的名字，而是触发关系本身：Page Cache 允许写入先发生、落盘后发生，而回写机制负责决定这个“后”具体什么时候到来，以及以什么节奏到来。

一旦把回写纳入模型，Page Cache 与内存管理之间的关系也就清楚了。很多初学者会把文件缓存和内存回收看成两张表，一张管 I/O，一张管内存，仿佛彼此只是偶然共享了物理页。实际上它们是同一个系统的两个侧面。缓存之所以能够提高性能，是因为内核愿意拿内存去换 I/O；缓存之所以不能无限膨胀，是因为同一份内存还承担着匿名页、内核对象、协议栈缓冲等其他职责。当内存充足时，Page Cache 可以显得非常慷慨，热点数据可以长期保留，突发写入也可以被吸收；当内存紧张时，系统就必须把“缓存命中收益”与“内存占用成本”重新结算。干净页因为可直接丢弃，回收代价较低；脏页则不能简单回收，必须先经过回写，因而它们不仅占内存，还会把回收问题转化成 I/O 压力问题。这种从内存压力传导到写回压力、再从写回压力传导到设备队列和应用延迟的链条，是存储系统抖动的重要来源。

异常路径会进一步暴露 Page Cache 的边界。应用进程崩溃并不自动意味着数据丢失，因为数据可能早已被复制到内核页缓存；但系统掉电或内核崩溃时，仍停留在 Page Cache 里的最新状态就可能全部消失。换句话说，Page Cache 提供的是内核接管后的可见性与调度便利，而不是天然的持久性保证。很多工程事故都源于对这件事的误判：开发者看到 write 返回成功，就把它当作“文件已经写好了”；实际上系统只是把修改放进了“未来要落盘”的队列里。也因此，Page Cache 天然会把问题继续推向后面的主题：什么时候算真正提交，哪些同步接口能够把脏页推进到更可靠的边界，文件系统日志又如何在崩溃后解释这些中间状态。只要这个桥没有搭起来，缓存层和持久化层之间就会长期混淆。

性能收益与工程代价也正是在这里同时出现。Page Cache 通常能显著改善顺序读、热点读和小块写的表现，因为它让大部分应用请求不必直接面对设备延迟；它还能吸收短时写突发，把很多原本尖锐的前台阻塞转移为后台批处理。但代价同样清楚。第一，它会占用相当可观的内存，而这部分内存并不总能稳定地带来收益，尤其在工作集频繁变动或应用自己也维护大缓存时。第二，后台回写并不是免费的，当脏页积累过多或内存压力陡增时，系统可能突然进入集中回写阶段，形成抖动和尾延迟恶化。第三，它会让应用层“成功”的含义变弱，因为成功先对应的是进入缓存，而不是进入稳定介质。第四，对于数据库、对象存储或用户态存储引擎这类本就希望自己控制缓存和刷盘节奏的系统，Page Cache 还会引出双重缓存、重复拷贝和不可控回写时机等额外问题。

这也是为什么不是所有场景都愿意依赖 Page Cache。有些数据库希望自己定义缓存淘汰、预读和脏页刷出策略，因为它们掌握更贴近业务的访问信息；有些高性能存储引擎更关心可预测延迟，而不是通用路径上的平均吞吐；还有些用户态 I/O 框架追求绕开内核里的通用缓存与调度层，以减少路径长度、上下文切换和不可控状态。于是 O_DIRECT、Direct I/O、用户态轮询框架和 SPDK 这类方案才会出现。它们并不是在宣称 Page Cache 没价值，而是在做一笔很明确的交换：放弃通用缓存层自动带来的部分收益，换取更短的路径、更强的时序控制和更清晰的资源归属。

如果要把这一主题压缩成一个便于后续展开的模型，我会把 Page Cache 看成“文件数据进入内核后最早形成的状态池”。读路径关心的是页是否已经在池中，写路径关心的是修改是否已经登记到池中，而系统调度关心的是这些页何时从池中被回写、何时被回收、何时把压力继续传递给上层调用者。只要抓住这三件事，后面的很多主题就会自然衔接起来：fsync 讨论的是怎样强行推进这座状态池里的某些修改，日志与崩溃恢复讨论的是系统在池中和池外状态不一致时如何重新建立提交边界，块层与多队列讨论的则是这些被推进出去的写入在下游如何继续演化。所以这篇文章真正应该建立的，不是“Page Cache 有哪些知识点”，而是一种统一视角：从应用发出 I/O 的那一刻起，数据首先成为内核管理的状态，而 Page Cache 就是这套状态机的第一现场。

关联文章

匹配标签：Page Cache, Linux I/O

• 命令write的执行过程
• 命令ls的执行过程