Linus用Claude Code写补丁，给内核多线程读文件提速

Linux 7.3-rc7发布前的等待期里，Linus Torvalds的个人内核Git仓库多出了一个分支，名叫noref-filemap-read-with-llm。

Torvalds平时基本只维护主分支，单开专题分支本就少见，名字里还明晃晃带着LLM，等于提前把用了AI写在了门牌上。随后的补丁说明里他讲得很直接：这组改动是在他指导下借助Claude Code完成的。AI写了实现，写了测试程序，参与了代码审查，还起草了补丁系列说明的初稿。性能测量在他自己的机器上跑。

要解决的问题很具体。多个线程同时读同一个文件的小块数据时，哪怕数据早就躺在页缓存里，每次读取仍要对folio做引用计数。多核机器上，大家反复更新同一个共享计数，缓存一致性流量上涨，核心之间互相等，读性能就卡在这里。

folio是内核近几年用来管理成组内存页的抽象，逐步替代老的单页管理方式。引用计数保证一块内存在被访问期间不会被提前释放，删不得，只能想办法少做。

补丁的思路是调整读取路径，在满足特定条件时直接从页缓存取数据，跳过常规的folio引用管理。难点在正确性，省掉的同步操作不能换来释放后使用或数据损坏。

单线程程序几乎感觉不到这类开销，高并发服务器、数据库、构建系统这类同时读大量文件的负载才是受益者。在针对性的测试场景里，补丁带来了相当明显的性能变化，但那是特定条件下的结果，换一种访问模式、线程数或硬件配置，收益可能有限。

目前补丁还在Torvalds的个人分支里，没进主线。按节奏它可能在7.4合并窗口期间被拿出来讨论，能不能合并要看审查和测试。

Torvalds对AI一向务实。

他之前谈过用AI辅助调试内核，在内核之外也试过Google的Antigravity等编程工具。他公开表达过的立场是，不因为代码用了AI就拒收，看的是质量和效果；同时内核维护者确实被越来越多AI生成的低质量补丁和错误报告消耗了审查精力。

这个分支正好是他认可的那种用法。问题是他挑的，方向是他定的，性能数字是他亲手测的，Claude Code干的是把思路变成代码、测试和文档的体力活。一个对内核内存管理了如指掌的人这样用AI，和外行让AI批量生成补丁往邮件列表里投，是两回事。