Torvalds 让 Claude Code 写内核补丁：页面缓存小读提速3倍，尚未合并

Linux 内核页面缓存的每次小读操作都要对 folio 做一次原子引用计数增减。当多个核心同时读取同一文件时，这个共享缓存行会在核心之间反复弹跳，成为并发读的主要瓶颈。Linus Torvalds 近日在自己维护的 Linux 树中推送了一个名为 noref-filemap-read-with-llm 的分支，用八个补丁重新实现了这一路径，并明确标注代码、测试程序、问题清单乃至封面信草稿均由 Anthropic 的 Claude Code 在其指导下生成。

补丁改了什么

现有实现中，每次从页面缓存做小读都要取一次 folio 引用再释放，这是对同一缓存行的原子写操作。在 Torvalds 的 Core i7-8565U 笔记本上，八个线程对同一文件做 16 字节 pread() 调用时，这一行占了跨核 load HITM 事件的 99.92%。此前已有内核开发者在 2024 年基于客户工作负载报告过这一瓶颈，Phoronix 则是在等待 Linux 7.3-rc7 标签时注意到该分支。

新方案借助 RCU 机制绕开引用计数：离开缓存的 folio 要经过一个宽限期后才归还页面分配器，因此读者可以直接从页面拷贝数据而不触碰引用计数。代价是这些页面会在短暂时间内滞留、无法被复用。八个补丁中有两个用于加装安全阀——当某个 CPU 排队的页面超过 1024 个时强制触发加速宽限期——但 Torvalds 仍称延迟释放是整个系列中「解决得最不彻底的部分」。

RCU（Read-Copy-Update） 是 Linux 内核中一种以读端零开销著称的同步机制。其核心思路是：读操作不加锁，只依赖指针的原子读写；写操作则先创建新副本，再以原子方式替换指针，旧副本不立即释放，而是等待所有正在进行的读者都离开临界区后再回收。这段等待期称为「宽限期」（grace period）。判断宽限期结束需要确认每个 CPU 都已发生过一次上下文切换或处于空闲状态，因此经典 RCU 的宽限期通常是毫秒级，内核为此提供了 synchronize_rcu()、call_rcu() 等接口。宽限期的代价正是延迟回收：旧数据在被释放前会额外占用内存，若读者持续活跃或 CPU 长期处于忙循环中，宽限期会被拉长。本补丁利用的正是这一性质——离开页面缓存的 folio 不立即归还分配器，而是挂入 RCU 回调队列，从而让后续读者无需触碰引用计数即可安全拷贝数据；Torvalds 加的 CPU 排队阈值（1024）就是为了防止宽限期被无限拖长导致内存耗尽。

perf c2c 是 Linux perf 工具集中专门用于诊断缓存到缓存（Cache-to-Cache，C2C） 伪共享与缓存行弹跳的子命令。它通过采样硬件性能计数器中的 HITM（Hit Modified）事件来统计：当一个核心访问的缓存行正被另一个核心以 Modified 状态持有、必须跨核转发时，就会产生一次 HITM。perf c2c 会解析每个 HITM 事件对应的内存地址、涉及的两个 CPU、以及触发访问的指令与调用栈，并按缓存行聚合，输出「哪个变量被哪个线程反复弹跳」的排行。因此它比通用的 perf stat 更能定位到具体的字段或结构体成员。文中 load HITM 从 30538 降到 101，意味着原实现中几乎每次小读都在跨核搬运同一个 folio 引用计数字段所在的那一行缓存；新方案消除了这一热点，剩下的 101 次大约来自其他不可消除的共享访问。使用 perf c2c 通常需要 root 权限并挂载 perf_event_paranoid 到足够宽松的值。

数字，包括倒退的那些

以下数据均来自同一台 4 核 8 线程笔记本，测试时关闭了 CPU 缓解措施。八线程单文件场景下，每次读的周期数从约 2950 降到约 725，每秒读取次数从 990 万至 1040 万提升到 3000 万至 3300 万；单线程场景下周期数从 452–454 微降到 408–409；perf c2c 的 load HITM 从 30538 降到 101。

但发布的数据里也保留了倒退项：单线程将 16 字节读入未映射用户页时，周期数从约 4150 升到约 6550。内存压力测试同样暴露了问题——在 2 GiB 虚拟机中，尚未加入安全阀补丁的六补丁版本在 4 核和 8 核配置下触发了 OOM killer，而完整系列在 1、2、4、8 核下均完成。Torvalds 预计更大规模和多路机器上收益会更明显，但尚未测试这类硬件。

需要提醒的是，三倍这个数字只来自一台机器，且由指导该系列的人测得。在引用它描述你自己的服务器之前，最好先在自己的硬件上测试该分支。

把封面信当作审查清单来读

封面信明确交代了分工：Claude Code 在 Torvalds 指导下产出上述所有被署名内容，基准测试跑在他自己的机器上。This is not a one-off——It's FOSS 还链接了此前一次 AI 辅助修复 Intel Xe 显卡驱动 bug 的记录，Torvalds 在布拉格 Open Source Summit Europe 上也说过「我其实真的很喜欢用 AI」。

这段分工可以拆成四条可复制的习惯，适用于任何提交给团队的智能体编写变更：在分支名或 PR 标题中声明由智能体编写，让审查者调整阅读方式；自己在点名过的硬件上跑数字，智能体可以写基准测试，但结果由你负责；把倒退项与收益以同样的精度并列发布；保留一份开放问题清单，并让智能体参与撰写——在别人花时间之前，让它先审查自己的工作是低成本的。

内核已有现成规则

无需自创披露格式。内核的 AI Coding Assistants 指南要求贡献携带 Assisted-by: LLM [TOOL1] [TOOL2] 标签，其中工具为 coccinelle、sparse 等可选分析工具，并明确规定「AI 智能体不得添加 Signed-off-by 标签」，因为只有人类才能认证 Developer Certificate of Origin。人类审查所有 AI 生成代码并承担全部责任。

在自己的仓库里用普通 git 就能沿用同一约定。提交时加上 trailer 和自己的签核：

git commit -s --trailer "Assisted-by: LLM"

审查者随后可以列出某分支上哪些提交由智能体辅助：

git log main..HEAD \
  --format='%h %s %(trailers:key=Assisted-by)'

--trailer 选项和 %(trailers) 占位符都是标准 git 功能。

Developer Certificate of Origin（DCO） 是 Linux 内核等开源项目要求贡献者签署的一份声明，其文本规定：提交者证明自己有权提交该代码，且该代码的贡献符合项目许可证。内核通过提交信息中的 Signed-off-by: 姓名 <邮箱> 这一 trailer 来体现签署，使用 git commit -s 自动附加。这个标签不是版权转让，而是一种法律上的「来源保证」，因此必须由具备法律主体资格的自然人（或获授权代表法人的人）给出，且姓名与邮箱必须真实可追溯。正因如此，内核的 AI 助手指南才明确规定「AI 智能体不得添加 Signed-off-by 标签」——LLM 无法承担 DCO 所要求的法律责任，也无法被追责。相反，Assisted-by: 只是一个事实性标注，告诉审查者该提交中哪些环节由工具参与，不承载法律承诺，因此可以指向 LLM、coccinelle、sparse 等分析工具。实践中，人类贡献者在 git commit -s 时保留自己的 Signed-off-by，再另加 Assisted-by，从而让「责任归属」与「工具披露」两个维度分离且可审计。

工程实践的启示

Torvalds 的这个分支把智能体产物隔离在命名分支上、分块审查，这恰好是许多 AI 辅助开发工具围绕构建的工作流。对于使用 Claude Code 等编码智能体的开发者，这次事件的核心价值不在于三倍数字本身，而在于一种可复用的协作范式：智能体承担代码生成、测试编写和问题清单起草，人类负责方向、硬件验证和最终合并决策。补丁尚未合并，也正说明这套流程中人类的把关环节并未被绕过。