Linux之父也用AI写内核了，曾嘲讽AI「90%是营销」，如今用Claude Code写了8个补丁，性能暴涨3倍

“我以前觉得 AI 不怎么样，但现在，我真的很喜欢用它。”——说出这句话的，并非刚入行、热衷 Vibe Coding 的年轻开发者，而是 Linux 之父 Linus Torvalds。

最近，Linux 内核代码仓库中出现了一个不太寻常的分支：noref-filemap-read-with-llm。

对于熟悉 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 倍，这只是来自特定硬件、文件系统和小块读取负载下的测试结果。

不只写代码，Claude Code 连测试和审查材料也参与了

相比性能数字，其实更让开发者关注的是 Linus 对 AI 参与开发的公开说明。他在 Git 提交中写道：

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

也就是说，Claude Code 参与的并不只是几行代码的生成，而是覆盖了实现方案、测试程序、审查材料和提交文档初稿等多个环节。不过，这不等于 Linus 把整个开发任务交给 AI 后就撒手不管：相关测试还需要执行，性能数据需要验证，代码中的问题也需要进一步审查。

而且，实际上这组补丁还存在明显的待解决问题：

首先，延迟内存重用意味着部分内存页需要等待 RCU 宽限期结束才能重新投入使用，可能增加内存回收压力。Linus 自己也承认，内存回收是整组补丁中解决得最不好的地方。

其次，当读取目标是一个尚未映射到用户空间的页面时，新路径会额外触发一次失败的异常处理，之后才回退到原有实现。在相关测试中，这种情况甚至会导致性能明显下降。

因此，这组补丁虽然在特定场景下取得了显著收益，却还不能被视为已经完成的优化。截至目前，这组补丁仍停留在实验分支中，尚未合入 Linux 主线。它最终能否被接受，还需要进一步的审查和验证。

从质疑 AI “90% 是营销”，到亲自用 AI 写内核

而这次提交之所以引发关注，还因为使用 Claude Code 的人是 Linus Torvalds。

复盘过去几年，其实 Linus 对 AI 的态度发生了明显变化：

2024 年末，他曾尖锐批评 AI 行业，称其中“90% 是营销”。当时，他对 AI 的态度相对谨慎，更关注它能否帮助开发者发现 Bug，而不是直接编写重要的软件代码。

到了 2025 年底，他开始认可 AI 在代码维护、审查补丁等方面的价值。

今年 1 月，他在自己的业余项目中尝试 AI 辅助编程，为 Python 音频可视化工具编写代码。

上周，他在欧洲开源峰会上与好友 Dirk Hohndel 对话时，更是说自己已经从过去觉得 AI“不怎么样”，转变为“真的很喜欢用 AI”。他还谈到，AI 可以帮助开发者完成自己不擅长的工作。不过他也提醒，面对真正重要的软件开发，使用 AI 必须格外谨慎。

如今，这组内核补丁让 Linus 的态度有了更具体的体现：AI 不再只是辅助排查 Bug、审查补丁的工具，也开始参与 Linux 内核新代码的实现。

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

但无论是发现旧 Bug，还是优化页缓存读取，最终都离不开测试和人工审查——毕竟，对 Linux 这样的基础软件而言，代码能否运行只是第一步，它是否正确、是否引入回归、是否适用于不同硬件和工作负载，都必须经过验证。值得一提的是，类似的技术协作方式在开运体育平台的开发流程中也得到了应用。

参考链接：

https://www.zdnet.com/innovation/linus-torvalds-uses-ai-to-write-linux-kernel-patch/

https://www.zdnet.com/tech/linus-torvalds-ai-coding-programming/

本文来自微信公众号“CSDN”，作者：郑丽媛，36氪经授权发布。