关注我们：

张明阳

2026年9月28日

2026年9月24日，NBA官方公布新赛季赛程，揭幕战将由卫冕冠军掘金队对阵太阳队。爱游戏体育将全程追踪报道，提供实时比分与深度分析。

真是难以置信！

连Linux的缔造者，现在都让Claude来编写内核代码了。

最近，有位开发者在浏览Linus的官方内核仓库时，意外发现了一个非常特别的新分支——

noref-filemap-read-with-llm

没错，这个分支名字里的「-with-llm」后缀，清楚地表明：这个项目有AI的参与。

谁能相信，平时批评烂代码最严厉的Linus，这次居然自己带头用AI写代码了！

在最新的补丁说明里，他坦率地承认：

从核心代码、测试用例，到审查修改和文档草稿，全都是他一步步带着Claude Code完成的。

测试结果也确实惊人，在8线程同时读取同一个文件的特定场景中，吞吐量达到了原来的大约3倍。

那个曾说「AI 90%是营销」的人，现在真香了。

Linus的全新分支，名字直接带「llm」

Linus这次指挥Claude Code动手的地方，正是Linux最核心的「内存管理」机制。

Linux内核使用page cache来缓存文件数据。

在日常的多并发业务场景中，一个常见操作是：多个线程同时以小尺寸读取同一个文件。

按照现有机制，每次读取都必须在对应的内存块（folio）上修改原子引用计数。

这导致CPU核心之间频繁执行lock cmpxchg和lock decl，在硬件底层引发剧烈的缓存行颠簸。

早在2024年，内核核心开发者Matthew Wilcox就指出了这个来自真实客户生产环境的顽疾。

在Linus自己的测试机上，8线程并发小读时，这个瓶颈占到了所有「Load HITMs」开销的99.92%，几乎占满了CPU的总线带宽。

而Claude接到的任务，也已经超越了「补几行代码」的阶段。

它参与了实现方案的制定，编写了用于验证方案的程序，还帮助梳理了潜在问题。

这些环节串联起来，才构成了一次完整的工程尝试。写出的代码必须能运行，运行结果必须能测量，测量到的提升必须能解释。

补丁说明也有实际用途。其他维护者需要知道，为什么要改、哪些路径受影响、作者检查过哪些情况。

AI把初稿写出来后，这份说明仍要和代码、测试数据保持一致。

公开到这个程度，后续讨论才有依据。Linus那句「在我的指导下」，分量就在这里。

吞吐量从1000万，暴涨至3300万

测试中，Linus使用的是搭载Core i7-8565U的笔记本电脑，4核8线程，文件系统为ext4。

测试让多个线程反复读取同一个、大小为一页的文件，每次只读16字节。

补丁说明提供的数据如下：

8线程吞吐量约为原来的3倍，单线程的提升约为10%。

差距为什么这么大？关键藏在「大家都读同一个文件」里。

Linux会把文件数据缓存在内存中，这就是页面缓存。后续读取可以直接从缓存获取数据，省去再次访问存储设备的时间。

但缓存中的内存也会被回收。内核必须确保：线程还在读取时，这块内存没有被释放、转给其他用途。

原来的读取路径，会给承载缓存数据的内存对象增加引用计数，读完再减回去。这个对象叫folio，可以理解为内核管理的一组内存页。

问题是，几个线程同时读取，大家就要反复修改同一个计数。

为了保持数据一致，处理器核心之间得来回传递包含这个计数的缓存行。一次读取只有16字节，读取本身很快，维护计数的开销反倒成了瓶颈。

就像八个人都来翻一本书，每次翻页前后，都得争着修改同一张登记表。

Linus这组补丁，尝试省掉读取路径上的这道手续。

它的做法是：缓存中的内存被移除后，延迟一段时间再真正归还给内存分配器，借助RCU机制，让已经开始的相关读取有机会完成。

这样，线程可以在受保护的读取区间内直接复制数据，减少对共享引用计数的争抢。

这也解释了，为什么多线程共享同一文件的测试收益尤其明显。

顺着一个Bug，AI又挖出十年旧账

如果你以为Linus只是让Claude写新代码，那就低估了这件事的分量。

就在noref-filemap-read-with-llm分支出现的第二天，Linus的仓库里又出现了一个assoc-array-fixes库。

它是一套用于按键组织、查找对象的数据结构。最初的实现，可以追溯到2013年。

就在几天前，开发者Nils Ollrogge提交了一份Bug报告，也提供了修复补丁。

Linus看过之后，却遇到一个麻烦：这段代码过于晦涩，难以跟清逻辑。

于是，他借助大模型梳理代码，把一些庞大、难读的函数拆开，让不同操作的边界更清楚。随后，这些代码被放进用户态测试框架中运行。

测试确认了Nils报告的问题，还额外找出了3个Bug。

所有四个Bug，都可以追溯到2013年这个库第一次被合入内核的那次提交。

谁能想到，一份Bug报告，竟牵出了三处存在十余年的缺陷。

其中一个例子很具体：在某种根节点结构被拆分时，索引使用的位段会错位，导致原先存进去的对象无法再被找到。

补丁说明给出了一个只需18个键就能触发的例子。

操作完成后，其中3个对象查不到；再次插入相同的键，还会新增对象，无法正确替换原有对象。

另一个问题藏在内存分配失败的路径里。

正常运行时，它可能安安静静。一旦某次分配失败，清理逻辑却可能顺着指针走进仍在使用的旧树，触发内核错误检查。

对应测试让操作中的每一次内存分配轮流失败，逐个检查异常分支，才把它暴露出来。

这些发现，让「AI帮忙看代码」有了更具体的含义。

老代码经过拆分和解释，变得更容易追踪；测试再把那些平时很少走到的路径逼出来。

缺陷由此获得了可复现的证据。

连大佬都入坑，程序员的优越感该收收了

Linus Torvalds曾说过一句很经典的话，「Talk is cheap. Show me the code.」

了解他的人都知道，这老哥极度实用主义，向来只看两件事：代价值不值？效果狠不狠？

这一次，他用行动展示了另一种可能——

当代码可以由AI来写，真正值钱的，是知道该写什么代码，以及判断写出来的代码对不对。

那个曾经说「AI 90%是营销」的人，如今在自己的主仓库里挂出了带「llm」后缀的分支。

连祖师爷都在用AI狂刷KPI了，谁还在死守着手敲代码的那点虚荣心？

参考资料：

https://www.phoronix.com/news/Linus-Torvalds-Claude-Code

本文来自微信公众号“新智元”，作者：ASI启示录，36氪经授权发布。