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

“我过去对AI持保留态度，但现在，我真的很享受使用它。”——说出这番话的，并非初入IT行业、沉迷于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氪经授权发布。