Linux之父用Claude Code重写内核页缓存读取，吞吐涨3倍-字节棱镜 (Byte Prism)

Linux 内核仓库里悄悄多出一个分支，分支名后缀带着「LLM」。点开补丁说明署名那一栏，写的是：在 Linus 指导下，由 Claude Code 完成代码、测试、审查与文档初稿。8 个补丁，目前仍挂在 7.3-rc6 分支上，尚未合并到主线。[2][3]

Linus 此前从未在公开场合以这种方式标注 AI 参与。一个月后，他的仓库里又冒出一个名为 assoc-array-fixes 的标签，处理关联数组库中潜伏十三年的老 bug——同样由他本人指导大模型完成拆解。[6]

一、仓库里突然冒出来的分支，叫「noref-filemap-read-with-llm」

Linus 在等待 Linux 7.3-rc7 发布期间刷了一次自己的 Git 仓库，结果发现一个非常规分支：noref-filemap-read-with-llm。分支名后缀的「LLM」不是随手写的，补丁说明里明确指明：”This work was done under my direction with the help of Claude Code”，并把 AI 参与的范围交代得很具体——代码实现、测试程序、代码审查，以及补丁系列说明初稿，全部出自 Claude Code；性能数据则跑在 Linus 自己的机器上。[2][3]

这一系列共 8 个补丁。[1] 与通常情况下由 AI 直接投到邮件列表的”AI 生成补丁”不同：方向是 Linus 自己定的，patch 是从他的仓库 fork 出来的，最终的取舍权也在维护者本人手里。

二、半年前还在怒怼「AI 垃圾代码」，这次怎么就真香了？

时间线要拉回 2026 年 1 月。Linux 邮件列表那时掀起一场讨论：要不要在内核文档里为 AI 生成补丁单列一条提交规范？Linus 直接下场回怼——「别再继续这种愚蠢的讨论了」。[5]

那次反对的核心其实有两层：第一，专门写一段 AI 标注规范没用，因为「那些提交 AI 垃圾代码的人，根本不可能在补丁里标注『这是 AI 生成的』」；第二，他不想让内核开发文档卷入「AI 是末日还是革命」的站队，因此坚持文档中 AI 唯一合理的定位就是「工具」。[5]

把这两次放在一起看，立场并不矛盾。Linus 反的不是”AI 写内核”，而是”AI 投稿没人审就进主线”。这次他用 Claude Code 做的是另一件事：领域专家定方向，AI 在指导下落地，最后还是维护者本人把关。它从机制上规避了 Linus 半年前担心的”未经理解的 AI Slop 直接涌入内核”——因为写代码的人同时也是判断代码该不该合并的人。

三、folio 引用计数竞争：藏在页缓存里的两年老瓶颈

要理解这次补丁在改什么，得先回到 Linux 文件读取的最底层。

Linux 用页缓存（Page Cache）保存从存储设备读过的文件数据。当程序再次访问已经驻留在内存的文件内容时，内核通常能直接从内存返回，不必重新读盘。这是 Linux 文件系统性能的关键支柱之一。[2][3]

为了管理这些缓存页的生命周期，内核用了引用计数。当多个线程同时读同一文件的同一小块数据时，每次读取都要更新 folio 引用计数（folio 是 Linux 用来管理一组连续内存页的新抽象，正在逐步替代旧的单页管理方式）。[2][3] 读取完成后再释放——两步都是对同一结构体的原子写。在多核处理器上，这意味着同一缓存行不停在核间弹跳：缓存一致性流量上升，CPU 核心彼此等待。

单线程或低并发时这个开销几乎看不出。但在高并发服务器、数据库、构建系统等需要大量多线程读同一文件的场景里，这个引用计数就可能成为隐性瓶颈。[2][3]

这个具体的瓶颈，最早由内核开发者 Matthew Wilcox 在 2024 年从一个客户的生产负载里提出。[1][6]

四、在一台 i7 笔记本上，吞吐跑到了 3 倍

Linus 把这个 bug 在自己那台酷睿 i7-8565U 笔记本上复现了出来。这台机器 4 核 8 线程，正是触发问题的典型配置。复现场景很极端：8 个线程对同一页做 16 字节读。perf c2c 工具的统计显示，仅这一行代码就占到了跨核缓存命中转移的 99.92%。[6]

之前有人尝试过另一种方案：先把数据拷到栈上缓冲区，不做引用，事后再做正确性验证。但这条路卡在了”看不见的竞态”上——页被释放后，可能在同一个索引位置被新分配的页重新占用，验证逻辑很难发现这种问题。[6]

Linus 的方向反过来：不去检测竞态，而是把它绕掉。内核里页缓存的页离开缓存之后，要等一个 RCU 宽限期才回到页分配器；利用这一点，让处在 RCU 读侧临界区的读者直接把数据从内存页拷到用户缓冲区，根本不碰传统 folio 引用管理。这一设计对单次读取大小没有上限，等于把同步开销从热路径里彻底拿掉。[6]

收益直接体现在数字上。同样是 8 个线程读同一个文件，每次读消耗的内核周期从约 2950 降到约 725，吞吐从每秒约 1000 万次提升到 3000 万次以上，约 3 倍。perf c2c 测到的跨核缓存转移次数从 30538 降到 101。单线程场景也有约一成的提升。[6]

代价也不是没有。延迟释放意味着内存要等一阵才能复用，Linus 自己也承认这是整套补丁里”最没解决”的部分。为此 8 个补丁中设计了两道安全阀：当某个处理器排队的页数超过 1024 时，工作线程就强制走一次加急 RCU 宽限期，把这些页释放掉。这是一个典型的”为换主路径性能而接受边角退化，再用兜底机制控制扩散”的取舍。[6]

五、比起 3 倍数字本身，更值得关注的是几件小事

第一件：AI 在这次开发里覆盖的不只是写代码。它参与了测试程序、代码审查和补丁系列说明的初稿，等于把”写一个内核 patch”的全流程都跑了一遍。提交说明里那段道歉式的措辞——把 AI 局限在”在 Linus 指导下”——实质上展示了 AI 在内核这种最审慎场景下能走多远。[2][3]

第二件：差不多同一时间，Linus 仓库里多了一个 assoc-array-fixes 标签。开发者 Niels Olsen 报告了 Linux 关联数组库的一个缺陷并附上补丁，Linus 觉得那段代码太难读，就用大模型帮助拆解——把几个又大又绕的函数分开。测试不光确认了原始 bug，还另外找出三个，都追溯到 2013 年这个库刚进内核时，已经潜伏十三年。[6]

这两件事合起来看，可能比 3 倍吞吐这个数字更能说明现状：在内核这种最保守的开发领域，核心维护者已经不只是把 LLM 当成实验对象或对照样本，而是真的放进了日常开发流程里用。而这一切发生在 Linux 文档刚刚明确表示”AI 只是工具”之后不久。

这些补丁目前仍挂在 7.3-rc6 分支上，只在 Linus 的笔记本上测过，距离合并到主线、被发行版采用并被生产环境用上，还有距离。[1][6]

FAQ

这些补丁什么时候能合并到主线？我的服务器什么时候能用上？

参考 [1][6]，8 个补丁目前还挂在 7.3-rc6 分支，作者明确表示只在一台笔记本上测过。要先经过邮件列表审阅、与其他维护者讨论、加载更多硬件平台验证，才有可能进入下一个合并窗口。何时被发行版采用，则要看具体厂商的打包节奏。

3 倍性能提升适用于哪些场景？普通业务能享受到吗？

参考 [6]，3 倍吞吐是”多线程同时读同一文件的 16 字节小读”这一极端场景下的实测结果。数据库、构建系统、大型共享库加载等高并发读同一文件的负载最有可能直接受益；跨线程访问不密集或者 I/O 不命中内存的场景，提升只有单线程那一成（约 10%）的水平。换句话说，这是一个针对特定瓶颈的攻坚，而不是一项普适优化。

非内核开发者能用 Claude Code 做类似的底层性能优化吗？

参考 [2][3][6]，这次的关键是”领域专家 + AI”的协作模式：瓶颈的判断、方案的取舍、安全阀的设计都来自 Linus 本人，AI 在指导下负责把方案写成代码、测试和文档。普通开发者更现实的参考点不是”让 AI 全自动改底层”，而是先自己把领域知识吃透，再用 AI 把已经想清楚的方案落地。AI 在这次事件中承担的是加速器，不是决策者。