在刚刚结束的 Maintainers Summit 上,Linux 内核创始人 Linus Torvalds 当众承认:他用大语言模型写出了一组针对内核长期痛点的补丁,并已经把第一版 10 个补丁递交邮件列表进入社区审查。这是 Linus 第一次正式把 LLM 参与创作的代码推上 LKML。

这次修的是什么

补丁聚焦在 folio 的查找路径。folio 是内核里把多个物理页合并管理的数据结构,在文件读、内存映射、I/O 子系统里几乎无处不在;folio 的引用计数与锁竞争一直是性能优化绕不开的热点。

Linus 的思路很直白:识别出「热 folio」(被反复访问的 folio),在它身上设置一个"延迟释放直到 RCU 周期结束"的标记。RCU(Read-Copy-Update)是 Linux 内核里一种典型读多写少场景下的同步原语,核心思想是读者几乎无锁、写者通过延迟回收来避免冲突。在 RCU 保护下做 folio 查找这件事内核早就实现了,但这次的改动更进一步——在 RCU 保护下直接做 folio 数据访问本身,快路径里连引用计数都不需要拿了。

性能数据与已知问题

根据 Torvalds 自述,在一组读操作密集的基准上,性能达到了"数量级"的提升——也就是 10 倍量级,而不是常见百分之几、几十。这种程度的飞跃在内核的成熟子系统里已经很久没出现过了。

不过,LKML 的评审并不给面子:补丁发布没多久,社区就已经定位出一处竞态条件(race condition),还需要进一步修复。这其实正是 Linus 想要——他在峰会上说,用 LLM 写代码,真正的难点不在 AI 自己写得怎么样,而在社区评审能不能像审人类写的代码一样严格把它打回去。

它为什么重要

这件事的信号意义比补丁本身更大。过去两年,Linus 多次公开表达对 AI 生成代码的"不信任",NetBSD 等社区甚至直接把 AI 生成的代码列为污染源、禁止提交。但这一次,他亲自下场,把自己最擅长的内核子系统的代码交给 LLM 起草,然后走完整的 LKML 评审流程。

换句话说,LLM 写的代码能不能进 mainline,内核社区这次是认真的。Linus 实际上把"AI 是否能参与内核开发"这个哲学问题,变成了一个工程问题:能不能过评审、过 review、过 bisect、过长期测试。能就合,不能就扔,标准只有一条,不看出处看质量。

从冷启动到 LKML,这条链已经走通。下一个值得关注的节点,大概率是 -rc1 阶段这批补丁会不会被拣进 mm 或者 folio 相关维护者的分支。