Linus Torvalds 的 AI 补丁实现 23 倍性能提升，随后评审发现竞态问题

Linus Torvalds 发布了他首个由 LLM 辅助完成的重要 Linux 内核补丁系列，并称其在一项刻意设置为极端条件的合成测试中实现了 23 倍加速。数小时内，另一位内核开发者便发现了一处竞态条件，可能导致受影响文件位置从未写入的数据被暴露出来。

这一过程比单独任何一个标题都更重要。Linus Torvalds 的 AI 补丁并未证明 AI 助手可以自主修复 Linux 内核。它展示的是：专家如何借助 AI 探索困难设计、构建测试、记录决策，并将结果交由人类评审者审查。

因此，真正的竞争并非人类对抗 AI，而是专家主导的 AI 开发对抗无人负责的代码生成。Torvalds 提供了内核知识并承担责任，而 Claude Code 据称协助完成了实现、测试、评审和文档编写。随后，邮件列表完成了生产级软件开发所必需的工作：对结果提出质疑。

Linus Torvalds 的 AI 补丁瞄准了真实的扩展性瓶颈

该补丁解决了一个真实的内核竞争问题，但其 23 倍结果反映的是合成测试的性能上限，而非预期的应用性能。

Torvalds 于 2026 年 10 月 13 日发布了这组包含十个补丁的系列，主题为“Improve page refcount scalability”。该工作针对由 Linux 页缓存提供服务的常规 read() 和 pread() 系统调用。

页缓存会将近期访问过的文件数据存储在内存中。当所请求的数据已经位于 RAM 内时，它可帮助应用避免重复执行存储操作。

Linux 通过称为 folio 的结构组织这部分内存。一个 folio 表示一个或多个在物理上连续、由内核统一管理的内存页。

在读取缓存数据前，内核通常会增加相关 folio 的引用计数。该引用可防止在其他操作仍在使用这块内存时将其释放。

这一机制安全且成熟，但当大量处理器反复访问相同缓存数据时，也会形成一个共享竞争点。

每个处理器都必须更新同一条引用计数缓存行。缓存行是在处理器缓存之间交换的小块内存。

当数十个核心争相修改这条缓存行时，硬件必须反复在它们之间转移所有权。由此产生的协调开销可能远高于微小读取操作本身。

Torvalds 表示，真实用户在缓冲 I/O 的扩展性限制中遇到了这一问题。共享库、数据库文件、Web 服务器资源以及其他频繁读取的文件，都可能产生类似访问模式。

这一问题并非新近发现。Torvalds 写道，Matthew Wilcox 数年前就曾报告过面向用户的扩展性问题。

Torvalds 在当时的讨论中提出了一个粗略方案。他后来承认，该版本虽然曾在本地使用约 18 个月，却是有问题的。

Kiryl Shutsemau 在 2025 年开发了一个修订方案，但 Torvalds 表示该版本同样存在问题。Ilya Gladyshev 则推进了另一种设计，历经六个版本后，已知的根本问题仍未解决。

这段历史很重要，因为它界定了交给编码助手的任务。Claude Code 并非被要求从空白提示词中发明一种优化方案。它进入的是一场包含失败设计、已知约束、专家反馈和多年内核背景的讨论。

在已发布的补丁系列中，Torvalds 描述了一条快速路径：在合适的读取操作中避免获取 folio 引用，转而通过读-复制-更新机制保护访问，通常称为 RCU。

RCU 是一种同步技术，允许读取者访问数据，同时让回收操作等待合适的宽限期。该延迟确保旧读取者完成后，底层内存才可能消失。

这些补丁将频繁使用的 folio 标记为热数据，并将其释放推迟到 RCU 宽限期之后。符合条件的读取随后便可在不更新共享引用计数的情况下复制缓存数据。

快速路径仅适用于用户空间复制不会触发缺页异常的情形。缺页异常发生于进程访问的内存尚未为该操作即时映射时。

Torvalds 测得，修改前在 64 线程下每秒可执行 1330 万次读取。修改后，性能达到每秒 3.04 亿次读取。

每次读取的周期数从补丁前的大约 19,857 至 19,939，降至补丁后的约 735 或 736。每次读取的指令数下降幅度较小，从约 1,094 至 1,101 降至 959。

这种巨大差异来自消除对共享缓存行的写入，而非消除了大多数指令。这一区别同时解释了该优化方式及其狭窄的基准测试优势。

Torvalds 明确警告，没有任何真实工作负载会复现这一标题数字。他的测试在 Ryzen Threadripper 系统上，让每个处理器反复读取同一页面中的一小部分。

这对于引用计数竞争而言是一个刻意设置的恶劣场景。它清楚展示了扩展性限制，但并不代表正常的数据库或 Web 请求。

可信的结论要比“Linux 快了 23 倍”更有限。这些补丁在高度有利的条件下，消除了一个严重的同步瓶颈。

为什么 23 倍 Linux 性能主张需要语境

该基准测试验证的是机制的潜力，而非该补丁系列的生产就绪程度，或其对完整应用程序的影响。

报告中的 23 倍改进，比较的是一项内核操作在专门改动前后的表现。它并未衡量完整的数据库事务、应用启动、服务器响应或软件构建。

真实工作负载会在多个层面消耗时间：执行应用逻辑、跨越进程边界、管理锁、分配内存，并且有时需要等待存储或网络。

即使单条读取路径获得显著改进，应用层面的收益也可能很小。受影响的操作必须占据足够多的总运行时间，用户才会感受到差异。

Torvalds 对这一限制说得格外明确。他称该基准测试是人为设计的，并表示现实中的影响会小得多。

这种披露增强了技术论证，因为它将扩展性演示与部署承诺区分开来。它也避免让 23 倍这一数字承载超出数据所支持的意义。

有价值的结果在于扩展曲线的形态。补丁前，吞吐量停在每秒 1330 万次读取，而每次读取的周期数攀升至接近 20,000。

补丁后，吞吐量上升至每秒 3.04 亿次读取，且不再对存在竞争的缓存行进行共享写入。Torvalds 将修订后的路径描述为在该测试中几乎完美扩展。

这表明实现消除了预期中的限制因素。它并不能证明生产系统会以相当强度遭遇同样的限制。

大型服务器仍是最可能的受益者。它们拥有足够多的核心，能够放大在低负载笔记本上可能不可见的竞争问题。

数据库可以从同一缓存索引或数据区域服务大量请求。Web 服务器则可能向并发客户端重复返回相同的静态内容。

进程还可以映射或读取通用库。在每种情况下，页缓存都可能在多个 CPU 上提供相同数据。

不过，这些系统也带来了自身的同步、请求处理和内存行为。内核改动无法加速受影响路径之外所花费的时间。

工作负载的多样性又增加了一层复杂性。一些应用使用内存映射，而非重复调用 read()；另一些则采用直接 I/O 或应用层缓存。

即便都是缓冲读取，访问规模和局部性也各不相同。Torvalds 的测试反复复制一小块区域，没有生产环境中常见的中断因素。

该补丁的性能代价也需要更广泛的测量。RCU 延迟回收会改变内存可被释放的时机，从而可能影响系统其他部分的压力。

据报道，早期版本曾暴露出延迟回收和内存压力方面的担忧。这个十补丁系列试图解决这些问题，但仍需进行更广泛的测试。

因此，一项有说服力的评估必须涵盖多个维度。评审者需要吞吐量、延迟、内存消耗、回收行为，以及不同处理器架构上的结果。

他们还需要不利工作负载，包括文件截断、并发写入、缓存逐出、缺页异常和内存受限系统。

最初的内核分析将结果描述为数量级的基准测试改进，同时指出评审已发现一处竞态问题。这一表述准确概括了当前状态。

这仍是一项有前景的开发工作，而非可交付的性能保证。尽管评审中发现了缺陷，该基准测试仍解释了维护者为何会继续研究这一设计。

评估类似主张的开发者，应将基准测试背景与每个数字一并保留。工程知识库可帮助团队将测试命令、硬件细节、补丁和评审决策统一保存。

当令人印象深刻的微基准测试开始脱离其限制条件传播时，这种记录尤为重要。Linux 的讨论展示了一个谨慎主张如何迅速演变为更广泛的性能叙事。

真正的竞争是专家引导对抗无人负责的生成

Torvalds 的实验支持的是专家控制下的 AI 辅助工程，而非无监督代码提交。

Linus Torvalds 的 AI 补丁之所以具有不同寻常的分量，原因在于其指导者是谁。Torvalds 创建了 Linux，至今仍是其首席维护者，在评估内核并发和内存管理改动方面拥有数十年经验。

这种专业能力在模型生成或修改任何内容之前，就已塑造了整个工作。他选择了一个真实问题，理解先前尝试，约束设计，审查输出，并以自己的名义提交。

据初始报道所述，Claude Code 协助完成了代码、测试程序、评审以及说明文本的初稿。Torvalds 表示，这一切都在他的指导下进行。

这句话承载着核心责任。该助手扩大了一位专家能够尝试的实现和分析规模，但它并未成为承担责任的贡献者。

人类提交者仍必须理解设计。他还必须解释其中的权衡、回应异议，并在评审者发现问题后修改代码。

这一模式与提交者无法为之辩护的生成式补丁截然不同。Linux 维护者本已承受巨大评审压力，因此廉价的代码生成可能将昂贵的验证工作转嫁给志愿者。

内核的生成内容规则直接应对了这种失衡。无论使用何种工具生成内容，贡献者都必须理解并能够为自己提交的一切负责。

维护者可能会拒绝生成的工作、要求额外测试，或要求进一步说明。相关指南还建议公开所使用的工具、提示词、受影响部分和测试方法。

该框架将 AI 输出视为与其他工具生成的材料一样，同时也承认其存在独特的错误风险。责任仍由贡献者承担，而非审阅者。

Torvalds 也反对对 AI 工具实施一刀切的禁令。他的论点聚焦于能力与责任，而非某个编辑器或编程助手的道德地位。

编译器可以帮助不合格的开发者产出有缺陷的软件，也可以帮助专家更高效地产出正确的软件。

LLM 扩大了这一范围。它可以生成连贯的测试和替代实现，但也可能用看似合理的解释掩盖错误。

内核开发尤其适合揭示这种差异。补丁会经过公开邮件列表，经验丰富的专家可以质疑其假设，并要求提供具体证据。

这一流程更重视可复现的推理，而非润色精美的文字。如果代码违反并发性保障，再长的解释也没有多少分量。

这就是为什么 Torvalds 的参与并不能终结围绕 AI 编程的更大争论。他的专业能力代表了使用此类工具的最强有利条件之一。

大多数生成的补丁不会得到他的指导。许多提交者也缺乏识别助手何时提出不安全生命周期规则所需的知识。

这一实验仍为资深工程团队提供了有益的范式。AI 助手可以探索实现空间、构建基准测试、总结既往尝试，并协助编写文档。

当专家掌控目标并能够拒绝低质量输出时，这些益处才有意义。当生成取代理解时，它们就会变得危险。

因此，比较对象并不是“Claude Code 对比内核开发者”。Claude Code 是在由内核开发者设计并审阅的流程中运行的。

应根据这一流程是否更快地产生了更好的方案来评判它的贡献。最终衡量标准仍是能经受审查、测试和部署的正确代码。

一个竞态条件说明审查仍是安全边界

首次公开审查发现了一个正确性缺陷，这使该补丁系列同时成为 AI 实用性与局限性的证据。

Torvalds 发布该系列的当天，Kiryl Shutsemau 就发现 filemap_read_rcu_batch() 中存在竞态。竞态是指并发操作之间的时序会改变程序结果的情况。

问题序列涉及一个 folio 离开页面缓存，同时新的 folio 替换它。随后，并发写入可能在原始读取完成前扩展文件大小。

由于其释放通过 RCU 被延后，执行读取的处理器可能仍保有对旧 folio 的访问权限。在观察到新的文件大小后，它可能从这个过期对象复制数据。

Shutsemau 警告称，内核可能读取用户从未写入该位置的字节。他提出的修正会重新检查 folio 是否仍位于预期的页面缓存位置。

完整的竞态条件被描述为两个处理器之间的交错执行。这个具体序列为审阅者提供了一项可测试的精确正确性主张。

这一发现并不意味着该优化毫无价值。并发补丁通常需要多轮审查，因为局部有效的操作可能组合成不安全的全局行为。

但这也不能成为缺陷的借口。读取过期或非预期数据是严重的正确性问题，尤其是在许多应用程序都会使用的内核路径中。

重要的是，该补丁并未悄然进入某个发行版本。Torvalds 发布的是供审查的开发系列，审查流程立即对其提出了质疑。

这正是 AI 编程系统目前无法替代的边界。模型可以执行审查，但它的信心并非独立的正确性证据。

同一模型可能会重复它在实现过程中引入的假设，也可能遗漏其构建的测试之外的时序组合。

独立的人类审查带来不同的思维模型。Shutsemau 此前已在同一领域工作，因此能够将新机制与已知的生命周期风险进行比较。

测试依然必要，但无法枚举所有可能的处理器交错执行。内核开发者还会使用形式化推理、压力测试、消毒器以及针对特定架构的验证。

这次发现的竞态尤其具有启发性，因为基准测试结果看起来仍然出色。性能测试可以通过，而正确性缺陷可能正等待一个罕见的时序窗口。

这会形成一个熟悉的工程陷阱。惊人的数字会把注意力引向速度，而最重要的问题其实是有效性。

AI 辅助可能加剧这种影响，因为它能在短时间内生成更多代码、测试和解释。在独立审阅者检查其假设之前，数量可能让一项提案显得成熟。

Linux 内核的助手指南要求人类贡献者负责审查生成的代码并证明其来源。AI 代理无法自行添加人类的 Signed-off-by 认证。

该指南还要求提供可复现的漏洞、经过测试的修复、明确的限制说明，以及正确地将内容转交给维护者。这些要求将 AI 建议转化为可追责的工程提交。

还存在更广泛的安全担忧。自动化工具生成漏洞报告的速度，可能快于维护者调查它们的速度。

Linux 文档警告称，未经验证的 AI 辅助报告已经在消耗稀缺的审查能力。其安全指南要求报告者验证问题、准备修复方案，并说明无法测试的部分。

Torvalds 的系列位于这条界线负责任的一侧。他提交了代码、基准测试、局限性说明和可审查的机制。

然而，这一竞态证明，负责任的流程并不能保证首个修订版就是正确的。它保证的是错误拥有一条通向发现与修复的结构化路径。

这才是对 AI 辅助编程更现实的标准。目标不是绝无错误的生成，因为人类开发者同样无法做到这一点。

目标是建立一个在发布前捕获重大错误的开发体系。对于内核代码，专家审查仍是该体系决定性的安全层。

Linux 内核 AI 规则将责任置于工具身份之上

内核社区正逐步形成一条务实规则：工具可以提供协助，但人类必须理解、辩护并对结果负责。

Torvalds 补丁的时机之所以重要，是因为内核开发者正在积极讨论应如何处理 AI 辅助的贡献。这场争论涉及署名、提交质量、审阅者工作量和法律责任。

一派主张，只要 LLM 作出了实质贡献，就应明确披露。披露可以帮助审阅者了解补丁是如何生成的，以及哪些地方可能需要额外审查。

另一种观点认为，笼统的 AI 标签对代码质量说明不多。熟练的贡献者可以谨慎使用助手，而不合格的贡献者即使不用助手也能提交低质量代码。

两种立场都回应了真实的担忧。来源很重要，但标签不能替代技术评估。

持久的原则是通过人类贡献链实现问责。Linux 的开发者原产地证书要求由个人证明其有权提交一项变更。

AI 代理无法作出这种法律和技术上的声明。添加签署的人仍要对许可、来源、审查反馈和提交后的行为负责。

这一责任解释了为什么 Torvalds 的使用方式不同于匿名生成的补丁。他的名字并不能让代码变得正确，但它明确了谁必须解释并修复问题。

公开讨论还揭示了提交量与审查能力之间的紧张关系。生成式工具让产出看似合理的补丁变得便宜得多。

它们并没有让资深维护者的时间变得更便宜。每一项提交都可能需要架构知识、测试、讨论和后续跟进。

因此，即使每位提交者只花很少时间生成补丁，低质量补丁的洪流仍会给项目带来成本。开源社区无法吸收无限量的生成式工作。

内核政策正越来越关注减少这种不对称。贡献者应验证问题、测试修复、报告限制，并避免让维护者从头重建其推理过程。

这一标准并不只适用于 AI。机械化分析工具、静态检查器和脚本化转换，如果使用者不理解其输出，同样可能产生误导性的变更。

LLM 提高了风险，因为它们的结果往往看起来像是有意写成的。它们可以为建立在错误前提上的代码生成极具说服力的解释。

答案并不是拒绝每一个辅助生成的补丁。那会丢弃有价值的测试生成、重构支持、搜索、文档编写和替代设计探索能力。

答案是，在失败代价高昂的地方保留成本高的人类关卡。这些关卡包括具备知识的作者身份、独立审查、自动化测试和渐进式集成。

Linus Torvalds 的 AI 补丁清楚地展示了这一层级。模型协助产生了一种技术上有趣的方法和异常详细的基准测试。

Torvalds 提供了领域方向和公开问责。Shutsemau 提供了独立审查，并发现了危险的交错执行。

后续修订和测试必须决定这一机制能否经受考验。每一层都贡献了其他层无法单独提供的东西。

采用编程代理的公司也应注意到同样的分工。为开发者提供更快的生成器、却不投入审查资源，可能会增加组织风险。

团队还需要保存连接提示词、代码变更、测试输出、设计决策和审阅意见的记录。缺少这些背景，未来维护者将继承其理由难以重建的代码。

内核社区拥有数十年处理来自不同雇主、激励机制和技能水平贡献者的经验。其流程假定没有作者能自动获得信任。

AI 生成的代码应得到同样的怀疑，并在生成掩盖来源或理解程度的地方接受额外审查。这比随意采用工具更严格，但也比一刀切的禁令更有用。

接下来发生什么比头条基准测试更重要

三项信号将决定这项工作会成为有意义的内核改进，还是仅停留在具有启发性的实验。

第一个信号是经修订的补丁系列：它既要消除已报告的竞态，又不能破坏快速路径。提出的重新检查看似很小，但并发修复可能同时改变安全性和性能。

审阅者需要确认，在每个关键点，folio 仍属于预期的缓存位置。他们还必须寻找该系列其他部分中相关的生命周期窗口。

如果下一修订版在解决这些问题的同时保留核心机制，专家主导的 AI 方法将获得可信度。反复出现的正确性失败则会削弱这种解读。

第二个信号是在现实系统和工作负载上开展更广泛的基准测试。64 线程的合成结果确立了极端争用条件下的性能上限。

有价值的后续测试应包括数据库、Web 服务器、共享库访问、混合读写、文件截断和页面缓存驱逐。它们还应覆盖 Ryzen Threadripper 之外的处理器。

内存压力值得单独关注。延后释放 folio 可能改变回收行为，即使读取路径变得更快也是如此。

一项有力的结果应当展示可衡量的应用收益，同时不引发不可接受的延迟、内存或回收性能回退。现实世界中收益微小并不意味着该机制无效，但会降低其紧迫性。

第三个信号是维护者的集成决定。Torvalds 的公开树中存在一个分支，并不等同于代码已被接纳进某个发行版本。

该系列补丁必须经受内存管理专家之间的讨论。它可能被修改、拆分、重新设计、推迟，或最终放弃。

接纳意味着审阅者在修正后认为这一机制易于理解且便于维护。即使遭到拒绝，仍可能为未来的实现留下有用的测试、测量数据和设计经验。

这些信号比争论 Claude Code 是否“编写了 Linux”更重要。那种说法将问题选择、生成、测试、审查和责任混为一谈，构成了一个具有误导性的论断。

更准确的叙述既没那么戏剧化，却更具影响力。一位资深内核专家借助 LLM 重新审视了一个棘手的扩展性问题，并提出了一项很有前景但存在缺陷的方案。

该方案揭示了一条值得研究的性能路径。随后，公开审查发现了一个开发流程必须解决的缺陷。

对开发者而言，眼下的教训是应将生成速度与可信度区分开来。更快的草稿应当带来更快的实验，而不是更弱的验证。

对工程负责人而言，这个案例支持在部署编程智能体的同时投入审查能力。只有当团队能够测试、质疑并维护生成内容时，它才具有价值。

对开源项目而言，提交规则必须保护稀缺的维护者注意力。贡献者应带着证据、理解，以及愿意对修订负责的态度而来。

即使其当前形式始终未被合并，这个 Linus Torvalds 的 AI 补丁仍将值得关注。它留下了一份公开记录，展示了 AI 辅助如何在软件领域要求最严苛的审查文化之一中运作。

如今，有意义的问题都很具体。审阅者能否在不失去扩展性收益的前提下消除竞态条件？生产工作负载能否获得足以证明新增复杂性合理的收益？在模型会话结束多年后，最终代码是否仍易于理解？

关注下一版修订、更广泛的基准测试，以及维护者的决定。这些结果将比单独一个 23 倍的综合测试数字更能说明 AI 辅助系统编程的实际意义。