Linux 创造者兼长期首席维护者 Linus Torvalds 近期利用 Anthropic 的 Claude Code 工具，着手解决一个困扰开发者两年多的内核性能瓶颈问题。
Torvalds 提交了一组包含 10 个补丁的系列。在 Ryzen Threadripper 平台上运行的合成基准测试中，该补丁将读取吞吐量提升了 23 倍。此前，Torvalds 曾花费 18 个月尝试自行修复页面缓存中的引用计数瓶颈，但效果不佳；其他开发者的方案也未能彻底解决问题。新补丁通过从常见缓冲读取路径中移除 folio 引用计数操作来实现优化。不过，Torvalds 强调，在真实工作负载中，性能提升幅度会小于基准测试结果。
Claude Code 参与内核开发实验
尽管 Torvalds 曾公开批评夸大 AI 作用的言论，但他近期亲自参与了相关实验。Phoronix 发现其代码树中出现了一个名为 noref-filemap-read-with-llm 的实验分支，这在以严谨著称的 Torvalds 代码树中较为罕见。
该分支基于 Linux 7.3-rc6，包含 8 个提交记录，并明确标注了 Claude Code 的参与内容。
据 Torvalds 介绍，这组补丁的代码生成、测试程序编写及初步审查均由 Claude Code 在其指导下完成，性能测量则由他本人在本地机器进行。
值得注意的是，尽管补丁通过了 AI 的自查，但在合入主分支前的社区审查阶段，隐藏的竞争条件 Bug 被人类维护者发现。
性能飙升背后的技术细节与隐患
该补丁旨在解决棘手的内核并发问题。早期优化方案试图在不持有 folio 引用的情况下复制数据，但这极易在内存回收时触发竞争条件（Race Condition）。
后续演进的 rcu-free-v3 系列引入了全新的 PG_rcu_free 标志和 RCU 延迟回收机制。只要数据复制过程中未触发缺页异常，该机制就能在数据向用户空间复制期间为 folio 提供保护。
在 Claude Code 协助下，性能优化效果显著：
Linus 笔记本测试（8 线程）：吞吐量提升至原来的近 3 倍（从每秒 1000 万次增至 3300 万次），每次读取消耗的内核周期从约 2950 降至 725。
Threadripper 测试（64 线程高争用场景）：吞吐量从每秒 1330 万次跃升至 3.04 亿次，CPU 周期消耗从近 2 万骤降至 735。
然而，激进的性能提升伴随代价。第一版实现中，当等待页面超过 1024 个时会强制触发加速宽限期。此外，向未映射用户页面读取数据时会额外触发缺页异常，导致单线程读取 16 字节数据的开销从约 4150 周期升至 6550 周期。目前尚不确定该性能退化在最新版本中是否依然存在。
人类审查揪出致命竞争条件
在审查过程中，Oracle 工程师 Matthew Wilcox 对新的 PG_rcu_free 标志提出质疑，建议改用页面类型或在 RCU 宽限期后回收不活跃链表中的 folio。Torvalds 否决了这些方案，认为必须在 folio 仍可映射时设置标志，且仅从不活跃链表回收无法覆盖 truncate 和打洞操作。
随后，Arm 工程师及 Linux 内存管理维护者 David Hildenbrand 支持将标志限制在 64 位系统上。关键突破来自 Kiryl Shutsemau，他在 filemap_read_rcu_batch() 函数中发现了一个严重的竞争条件隐患。
Shutsemau 指出，在无引用的 RCU 读取路径中，原逻辑先获取当前 folio，再读取文件大小（i_size）。若在此期间旧 folio 被替换且文件大小扩展，读取路径可能使用旧 folio 快照却结合新扩展的 i_size 计算边界，导致将文件中尚未写入有效数据的空白区域返回给用户程序。
针对这一时序隐患，Torvalds 提出重构方向：提前读取文件大小（i_size），并将 folio 有效性检查与边界逻辑合并。Shutsemau 采纳该建议并更新了补丁，成功消除了这一潜在的数据错误风险。
参考链接：
https://www.phoronix.com/news/Linus-Torvalds-Claude-Code
https://thenewstack.io/torvalds-claude-code-kernel/
声明：本文为 InfoQ 编译，不代表平台观点，也不构成投资建议，未经许可禁止转载。
