Linus亲自带Claude Code改Linux内核：8线程小读快3倍，还翻出十年老Bug

导读：Linus Torvalds这次不是随口谈AI，而是把Claude Code带进了Linux内核实验开发：代码、测试程序、问题清单审查和说明初稿都有AI参与。在一项8线程、每次16字节、读取单页文件固定偏移的测试里，吞吐从约1000万次/秒升到3100万至3300万次/秒；另一个修复分支还复现出多项始于2013年的关联数组缺陷。

先把边界说清：这不是“Linux整体性能暴涨3倍”，也不是Claude Code独立改写内核。数据来自一台i7-8565U四核八线程笔记本上的特定微基准，相关代码位于实验分支；Linus明确写明AI是在他的指导下完成辅助工作，测量也由他在自己的机器上运行。

01 / 这一次，Linus把AI参与范围写进了提交说明

在名为noref-filemap-read-with-llm的Linux内核实验分支中，Linus没有模糊处理AI的角色。他在顶部提交说明里披露：代码、测试程序、已知问题清单背后的审查，以及说明文字的第一版，都由Claude Code在他的指导下协助完成。

这句话很关键。它既不是“AI只补了几行代码”，也不是“AI自己完成了内核优化”。更准确的描述是：资深维护者定义问题、选择方案并承担判断，编程代理负责扩大实现、测试、复核和文档整理的吞吐量。

02 / 真正要解决的，不是文件读取慢，而是多核争抢同一条缓存线

这组补丁关注Linux页缓存中的小型并发读取。传统路径在读取缓存页时，需要增加并随后减少folio引用计数，以确保对象在使用期间不会被释放。单线程下这项开销不算夸张，但多个核心同时修改同一个引用计数时，承载计数器的缓存线会在CPU核心之间反复转移。

可以把它理解为：八个人同时借阅同一本资料，每次都必须在同一张纸上登记“借出”和“归还”。真正拖慢流程的不是读资料，而是所有人抢着修改那张登记表。

实验方案把页缓存中已经移除的folio延迟到RCU宽限期后再释放，使读取侧能够在RCU保护下访问对象，而不必为每次读取增加folio引用。目标很明确：减少共享引用计数引发的缓存线争用。

03 / 3倍性能是怎么测出来的？完整测试条件比数字更重要

官方提交记录给出的环境是Intel Core i7-8565U，四核八线程，ext4文件系统。每个线程都对一个单页文件在偏移0处执行16字节pread()。结果如下：

为什么单线程只快约10%，八线程却接近3倍？因为这个优化的主要收益不是减少一般计算，而是消除多核心间的争抢。线程越多，共享引用计数的缓存线抖动越严重，绕开这条热点路径的价值越大。

04 / 不能只看峰值：这个方案也有明确代价

官方说明没有回避负面结果。把数据复制到用户空间时，如果目标地址触发缺页，新的无引用读取路径可能需要退出RCU、处理缺页后再重试，导致某些故障路径比原实现更慢。更大的读取和不同访问模式，也未必得到同等收益。

• 收益集中：缓存命中、数据很小、并发线程多时最突出。
• 单线程提升有限：约10%，说明原路径在无争抢时并没有慢到不可接受。
• 缺页路径可能退化：需要重试的数据复制会增加开销。
• 没有更大机器实测：提交说明对更大多核系统的收益只是合理预期，不是已经测得的结论。
• 仍是实验分支：后续还要面对更广泛架构、文件系统和工作负载验证。

做视频网观点：可信的性能文章不只展示“最好的一行”，还要交代硬件、线程数、数据尺寸、基线、失败路径和不能泛化的部分。Linus这次最值得学习的，正是把AI生成的候选方案重新放回可测量、可证伪的工程框架里。

05 / AI还翻出了始于2013年的关联数组老Bug

另一个assoc-array-fixes分支更能说明AI适合做什么。Linux内核的通用关联数组实现源自2013年前后，代码路径复杂、边界条件多。相关修复记录显示，AI辅助构造用户态测试和故障注入后，复现出多个长期潜伏的问题。

• 垃圾回收在分配失败时可能沿错误路径清理到仍然存活的树。
• 在已有shortcut之后继续链接shortcut时，特定插入与删除序列可以破坏结构。
• 根节点在特定层级拆分时，测试中的18个对象会丢失3个，并可能允许重复键。
• 在机器字边界拆分shortcut时，一组测试里102个键有76个无法再次找到。

这些案例的价值不在于“AI比Linus更聪明”，而在于编程代理可以耐心生成大量窄测试、反复缩小复现步骤，并把异常路径整理成维护者可审查的提交。对历史包袱重、测试稀疏的底层代码，这种能力很实用。

06 / Claude Code到底做了什么？与普通代码补全完全不同

这不是“把提示词交给AI然后下班”。AI负责加速可以自动化的部分，人类负责那些不能靠语言流畅度证明的部分：并发生命周期是否正确、性能数字是否可信、回归是否可以接受、补丁是否值得进入主线。

07 / 一套普通开发团队也能复用的AI编程教程

1. 先定义可测问题：不要让AI“优化整个项目”，明确到函数、调用路径、错误条件或性能指标。
2. 先做基线：记录硬件、数据集、版本、测试命令和波动范围，确保后续结果可重复。
3. 让AI给出候选解释：要求它列出热点、生命周期、锁竞争、缓存行为和可能回归，而不只是生成补丁。
4. 测试先行：为每个假设建立最小复现、边界测试、并发测试和故障注入。
5. 小步提交：把重构、行为修改、测试和文档拆开，方便定位哪个变化带来收益或回归。
6. 主动寻找反例：要求AI列出“在哪些情况下更慢”，并真的运行这些测试。
7. 人工审查关键不变量：尤其是内存生命周期、权限、并发、错误恢复和数据一致性。
8. 公开AI参与范围：说明哪些内容由AI协助、哪些测量由人执行，方便审查者调整注意力。

08 / 真正的信号：AI编程正在从“会写代码”走向“会做证据”

这件事最值得关注的，不是某位开源领袖终于“入坑AI”，而是AI编程开始进入最强调证据和审查的工程场景。对Linux内核而言，一段能编译的代码几乎没有说服力；测试、复现、性能边界、失败模式和维护者责任才构成完整补丁。

Claude Code这次真正证明的，不是它可以取代Linus，而是它能让Linus式的工程判断拥有更高吞吐量。模型可以写代码，也可以被要求同时写测试、找反例、整理问题清单和起草说明。人类最重要的能力，则从“亲手敲完每一行”转向“选对问题、定义证据、识别边界并承担决定”。

站内入口与延伸阅读

• Linux Kernel站内导航：https://www.zuoshipin.com/link/54450.html
• Claude Code站内导航：https://www.zuoshipin.com/link/28144.html
• Claude站内导航：https://www.zuoshipin.com/link/876.html
• Claude让Anthropic的Git合并量暴涨12倍：https://www.zuoshipin.com/article/54162
• 20% AI额度做出八成Word体验：https://www.zuoshipin.com/article/52242
• 豆包工作导入Claude Code与Codex资产：https://www.zuoshipin.com/article/54225

官方资料

• Linux官方无引用页缓存读取实验分支
• Linux官方顶部提交说明与AI参与披露
• Linux官方关联数组修复分支
• Anthropic Claude Code官方介绍