“我以前觉得 AI 不怎么样，但现在，我真的很喜欢用它。”——说这句话的，不是什么刚入行、热衷于 Vibe Coding的年轻程序员，而是 Linux 之父 Linus Torvalds。 整理 | 郑丽媛 出品 | CSDN（ID：CSDNnews） 最近，Linux 内核代码仓库里，出现了一个不太寻常的分支：noref-filemap-read-with-llm。 对于熟悉 Linux 开发的人来说，Linux 之父 Linus Torvalds 的代码仓库里出现一个新分支，本身就值得留意；而这次， 分支名末尾还直接写上了 llm——大语言模型。 10 月 10 日， Linus Torvalds 在自己的 Linux 内核仓库中提交了一项名为“mm: read from the page cache without folio references”的改动 。相关补丁很快引起了开发者社区的关注：这组包含 8 个补丁的实验性方案，不仅针对 Linux 内核中一个存在已久的性能瓶颈，还 明确 公开 了 AI 编程工具 Claude Code 的参与。 有意思的是，这组补丁给出的测试结果也相当亮眼：在一个特定的 8 线程文件读取测试中，吞 吐量从每秒约 1000 万次提高到最高约 3300 万次，提升超过 3 倍 ——不过，先别急着认为 AI 已经能独立开发操作系统，该补丁 目前仍处于实验阶段，性能提升也有明确的适用范围。 8 个补丁，瞄准一个困扰 Linux 两年多的问题 这次优化针对的是 Linux 的页缓存（page cache）。 简单来说，Linux 会把读取过的文件数据缓存在内存中，当程序再次访问这些数据时，操作系统就能直接从内存读取，减少访问存储设备的开销。但当多个线程同时读取同一个文件中的少量数据时，页缓存就可能出现一个意想不到的瓶颈：内存引用计数竞争。 为了确保数据被使用时不会遭到提前释放，内核需要跟踪承载文件数据的内存对象，也就是 folio。传统读取路径会增加 folio 的引用计数，并在读取完成后将其减回去。问题在于，这些操作涉及原子指令：当多个线程反复修改同一个计数器时，处理器核心之间就需要不断协调缓存数据的一致性，产生额外的开销。 如果每次读取的数据量很大，这些额外开销可能不那么明显；但如果每次只读取 16 字节，维护引用计数所花费的开销，就将远超真正读取数据的成本。 这并不是 Linus 临时发现的小问题。早在 2024 年，内核开发者 Matthew Wilcox 就已提出这一性能瓶颈—— 只是 这次 ， Linus 决定借助 Claude Code 来 解决 这个问题。 让 AI 帮忙改代码，多线程读取性能直接提升 3 倍 为了验证优化效果，Linus 用自己的笔记本电脑进行了测试： 设备搭载 Intel Core i7-8565U 处理器，拥有 4 个物理核心、8 个线程；当 8 个线程同时对同一个文件页面发起 16 字节的 pread() 读取请求时，性能分析结果显示，与跨核心负载相关的 HITM（命中处于修改状态的缓存行）事件中， 99.92% 都集中在相关共享缓存行上 。 也就是说， 测试中的大量跨核心协调开销，都与这条共享缓存行有关。 针对这个问题，Linus 与 Claude Code 尝试了一种不同的处理方式——新方案的关键，在于借助 RCU（Read-Copy-Update，读取-复制-更新）机制，调整内核何时能重新使用从页缓存中移除的内存。 原本，读取路径需要频繁获取和释放 folio 的引用。新方案则允许相关内存延迟归还给分配器，直到 RCU 宽限期结束。这样，在受到 RCU 读侧保护的代码段中，读取线程就可以直接把数据复制到用户空间缓冲区，不必再反复更新共享引用计数。 通俗来讲，就是 尽量绕开多线程反复争抢同一个计数器的过程，以减少不必要的协调开销 。如此优化下，测试数据显示出了明显差异： 在 8 线程并发读取场景中，吞吐量从每秒约 990 万～1040 万次，提高到约 3000 万～3300 万次。 每次读取所需的内核 CPU 周期，也从约 2950 个降至 725 个。 单线程场景下，收益则没有那么夸张：每次读取所需的 CPU 周期从约 452～454 个下降到 408～409 个。 从这些数据来看，性能收益主要集中在多线程并发读取场景。因为原本最大的开销就来自多个线程竞争共享缓存行，减少这类竞争后，并发场景的改善自然更明显。Linus 在提交说明中还指出， 如果换成拥有更多 CPU 核心或采用多路插槽架构的机器，理论上可能获得更大收益。 另外， “性能提升 3 倍”并不 表示 Linux 整体运行速度提升了 3 倍，这只是来自特定硬件、文件系统和小块读取负载下的测试