“我以前觉得 AI 不怎么样，但现在，我真的很喜欢用它。”

说这句话的不是刚入行、热衷 Vibe Coding 的年轻程序员，而是以严格和毒舌著称的 Linux 之父 Linus Torvalds。最近，他的 Linux 内核代码仓库里出现了一个相当直白的实验分支：noref-filemap-read-with-llm——分支名末尾直接写上了 LLM。

10 月 10 日，Linus 提交了一项名为 “mm: read from the page cache without folio references” 的改动。这组共 8 个补丁的实验性方案，不仅针对 Linux 内核中一个存在已久的性能瓶颈，还明确公开了 AI 编程工具 Claude Code 的参与。

测试结果也很抓人：在特定的 8 线程文件读取测试中，吞吐量从每秒约 1000 万次提升到最高约 3300 万次，性能提升超过 3 倍。不过，这并不代表 AI 已经能独立写操作系统，也不代表整个 Linux 都提速了 3 倍。

困扰内核两年多的页缓存瓶颈

这次优化针对的是 Linux 的页缓存（page cache）。

Linux 会把读取过的文件数据缓存在内存中。当程序再次访问这些数据时，内核可以直接从内存读取，减少访问存储设备的开销。但在多线程同时读取同一文件的少量数据时，页缓存会遇到一个容易被忽略的问题：内存引用计数竞争。

为了避免文件数据还在使用时就被提前释放，内核需要跟踪承载这些数据的内存对象，也就是 folio。传统读取路径会先增加 folio 的引用计数，读取完成后再减回去。这些操作涉及原子指令，当多个线程反复修改同一个计数器时，CPU 核心之间需要不断协调缓存一致性，从而产生大量额外开销。

如果每次读取的数据量很大，这笔开销还算可以接受；但如果每次只读 16 字节，维护引用计数的成本甚至会远超真正读取数据的成本。

这并不是 Linus 临时发现的小问题。早在 2024 年，内核开发者 Matthew Wilcox 就已经提出了这一性能瓶颈。而这一次，Linus 决定借助 Claude Code 来动手解决。

绕开引用计数，并发读取性能暴涨

Linus 使用自己的笔记本进行了测试。设备搭载 Intel Core i7-8565U，具备 4 个物理核心、8 个线程。测试中，8 个线程同时对同一个文件页面发起 16 字节的 pread() 读取请求。

性能分析显示，与跨核心负载相关的 HITM（命中处于修改状态的缓存行）事件中，99.92% 都集中在相关共享缓存行上。换句话说，绝大多数跨核心协调开销都来自这条被反复争抢的缓存行。

新方案的关键，是借助 **RCU（Read-Copy-Update，读取-复制-更新）**机制，调整内核何时能够重新使用从页缓存中移除的内存。

传统路径需要频繁获取和释放 folio 引用；新方案则允许相关内存延迟归还给分配器，直到 RCU 宽限期结束。这样一来，在受到 RCU 读侧保护的代码段中，读取线程可以直接把数据复制到用户空间缓冲区，不必再反复更新共享引用计数。

简单说，就是尽量绕开多线程反复争抢同一个计数器的过程。

测试数据的变化非常明显：

  • 8 线程并发吞吐量：从每秒约 990 万～1040 万次，提升到约 3000 万～3300 万次。
  • 8 线程每次读取的 CPU 周期：从约 2950 个降至约 725 个。
  • 单线程每次读取的 CPU 周期：从约 452～454 个降至约 408～409 个。

收益主要集中在多线程并发场景，因为原本最大的开销就来自多个核心竞争同一条共享缓存行。Linus 还指出，如果换成拥有更多 CPU 核心或采用多路插槽架构的机器，理论上可能获得更大收益。

【编辑观察】这里的“3 倍”有非常明确的限定条件：特定硬件、特定文件系统、特定小块并发读取负载。它是一次漂亮的底层优化，但不是通用场景下的 Linux 整体性能翻倍。

Claude Code 不只写代码，但补丁仍未进主线

更让开发者在意的，是 Linus 对 AI 参与范围的说明。他在 Git 提交中写道：

“上述代码、测试程序、围绕相关内容展开的审查，以及这段说明文字的初稿，都是在我的指导下，借助大语言模型编程助手 Claude Code 完成的。”

也就是说，Claude Code 参与的不只是生成几行代码，而是覆盖了实现方案、测试程序、审查材料和提交文档初稿等多个环节。但这并不意味着 Linus 当起了甩手掌柜：测试仍要执行，数据仍要验证，代码问题也仍需人工审查。

目前，这组补丁还有两个明显短板：

  • 内存回收压力：延迟内存重用意味着部分内存页需要等待 RCU 宽限期结束后才能重新投入使用。Linus 自己也承认，内存回收是整组补丁中解决得最不好的部分。
  • 未映射页面可能变慢：当读取目标是尚未映射到用户空间的页面时，新路径会额外触发一次失败的异常处理，再回退到原有实现，相关测试中甚至会出现明显性能下降。

因此，这组补丁虽然在特定场景下收益显著，却仍处于实验分支，尚未合入 Linux 主线。它最终能否被社区接受，还要经过更多审查、测试和不同硬件负载的验证。

从“90%是营销”到“真的很喜欢用”

这次提交之所以引发热议，很大程度上是因为使用 AI 的人是 Linus Torvalds。他过去几年对 AI 的态度变化，几乎可以拍成一条反转时间线：

  • 2024 年末：他曾尖锐批评 AI 行业，称其中“90% 是营销”，当时更关注 AI 能否帮助开发者发现 Bug，而不是直接编写重要代码。
  • 2025 年底：他开始认可 AI 在代码维护、审查补丁等方面的价值。
  • 今年 1 月：他在业余项目中尝试 AI 辅助编程，为 Python 音频可视化工具编写代码。
  • 近期欧洲开源峰会：他与好友 Dirk Hohndel 对话时表示，自己已经从过去觉得 AI“不怎么样”，转变为“真的很喜欢用 AI”，但也强调真正重要的软件开发必须格外谨慎。

这组内核补丁让这种态度变化有了更具体的落点：AI 不再只是帮忙查 Bug、看补丁的辅助工具，而开始参与 Linux 内核新代码的实现。

前不久，Linus 还使用 LLM 梳理另一处历史悠久、难以理解的内核代码。在 assoc_array 相关整理工作中，AI 协助他拆解复杂函数、准备用户态测试，最终发现了 3 个可以追溯到 2013 年的 Bug。

不过，无论是发现陈年旧 Bug，还是优化页缓存读取，最终都离不开测试和人工把关。对 Linux 这样的基础软件来说，代码能跑只是第一步；它是否正确、是否引入回归、是否适配不同硬件和工作负载，才是决定能否进入主线的关键。

AI 可以帮 Linus 写补丁，但暂时还替不了 Linus 的那道审查关。