一项由 AI 协助完成的内核贡献
Linus Torvalds 在 Linux 内核补丁系列的工作中使用了一款 LLM 编程助手，这对这一最具影响力的开源软件项目之一而言，是一个值得关注的时刻。在随工作提交的说明中，Torvalds 表示，在他的指导下，补丁列表中的代码、测试程序、审查工作以及解释性文字的初稿均由 Anthropic 的 Claude Code 完成。
这一披露并未描述一个自主系统独立修改 Linux。相反，它描述了在开发者主导的流程中，AI 如何被用于解决一个具体的技术问题。Torvalds 在其代码仓库中以名为 noref-filemap-read-with-llm 的分支发布了这组包含八个补丁的系列。
这些补丁针对一个已知的 Linux 性能问题：在多核、多处理器系统上，多个线程对同一缓存文件进行小块读取时会产生性能瓶颈。该问题自 2024 年以来就已为人所知，而此前尝试解决这一问题的方法并未奏效。
瓶颈位于页缓存
Linux 使用页缓存将文件数据保存在内存中。通常情况下，这有助于程序避免反复访问存储设备，但这组补丁所针对的是另一类成本：处理器核心之间的协调。
当多个线程反复从同一个缓存文件中进行小块读取时，它们会获取并释放承载这些数据的 folio 的引用。这些引用计数更新需要对共享缓存行执行原子写入。在多核系统中，由此产生的流量可能导致各核心争夺该缓存行，从而拖慢工作负载。
当读取操作规模较小且频率较高时，这种影响尤其明显。报告中的示例使用八个线程，对四核八线程的 Intel Core i7-8565U 笔记本电脑上同一页面执行 16 字节的 pread() 调用。在该测试中，共享缓存行占测得的跨核心负载活动的 99.92%；这类活动被归类为处于 Modified 状态的缓存行命中，即 HITM。
这一测量结果说明了，像引用计数更新这样底层的细节为何可能产生远超预期的影响。单次读取非常小，但当多个执行线程争用同一底层数据时，围绕共享内存反复进行的同步可能成为主要成本。
这一披露为何重要
Linux 开发有着严格的审查和测试要求，尤其是涉及内存管理和文件缓存行为的改动。因此，Torvalds 的声明之所以重要，与其说是因为其中使用了 AI，不如说是因为他明确说明了 AI 在生成内核补丁系列的代码、测试、审查材料和解释性初稿过程中所扮演的角色。
这一叙述也更具体地展现了 AI 编程工具可能如何被用于系统编程。该助手被应用于一个边界明确、行为可测量的性能问题，并配合测试程序和基于补丁的审查流程使用。Torvalds 仍然是指导工作并提交改动的人。
这一点对于评估相关说法十分重要。原始信息并未将这些补丁描述为模型取代内核维护者的案例，而是将 AI 描述为一种工具：在作者的指导下，用于处理一个复杂的多核内存缓存问题。
基础设施软件中的 AI 测试案例
基础设施代码是检验编程辅助工具能力的高难度场景。内核改动不能只是看起来合理，还必须考虑并发性、性能特征，以及只有在特定工作负载下才会出现的交互。在本例中，这项工作与页缓存中一个明确识别的争用机制以及一个具体的基准测试场景相关联。
这组补丁也体现了 AI 的使用范围已超越代码补全。Torvalds 的披露包括测试程序、审查工作以及配套文字的初稿。这些都是工程工作的不同组成部分，而这份声明表明，该助手被用于其中多个环节，同时技术方向仍由人类主导。
这种方法是否会成为 Linux 开发的常规做法，将由项目正常的技术流程决定：对补丁集进行检查，以及由维护者和贡献者开展测试与审查。眼下的结果范围更窄，但仍具有重要意义。开源领域最具影响力的维护者之一，已公开记录了自己如何在针对真实内核性能问题的拟议修复中使用 LLM 助手。
对于关注 AI 工具实际应用的开发者而言，这一事件提供了一个有用的观察框架。这项技术被用于一个具体且可测量的系统问题——不是为了替代工程责任，而是在负责人的指导下，协助制作和审查一组补丁。
本文根据 ZDNET 的报道编写。阅读原文。
Originally published on zdnet.com