Linux之父也有AI写内核，GCC设置15行红线
Linux之父也有AI写内核，GCC设置15行红线
视频通过 Linus Torvalds 使用 AI 编写 Linux 内核补丁与 GCC 限制 AI 生成代码的对比，指出核心问题是：代码进入项目后，版权能否得到保障，以及是否有人理解代码、签字并承担维护责任。
-
Linux 与 GCC 看似立场相反，实际都允许 AI 辅助开发。 据视频叙述，Linus 提交了由 Claude Code 在其指导下完成的内核补丁；GCC 则拒绝具有版权意义的 LLM 生成贡献，但允许 AI 辅助阅读代码、研究、查找漏洞和审查补丁。分歧主要在于是否接受生成内容进入代码库。
-
Linus 的补丁针对多线程读取文件时的引用计数争用。 内核读取文件时，需要找到页缓存中的 folio，并增加、减少其引用计数。多个 CPU 核心同时读取同一文件，会反复原子修改同一个计数器，导致所在缓存行在核心间来回传递。视频称，在其笔记本的 8 线程、每次读取 16 字节测试中，这条缓存行占跨核缓存争用的 99.92%。
-
优化方案是通过 RCU 延迟释放，让读取路径绕开引用计数。 folio 从页缓存移除时，设置
PG_rcu_free标记，等 RCU 宽限期结束后再真正释放内存，确保此前进入临界区的读者已经退出。这样可以直接把页内数据复制到用户缓冲区；单个 CPU 排队等待释放的页超过 1024 个时，会强制加速宽限期，避免内存积压。 -
基准测试提升显著，但适用范围与代价都很明确。
- 笔记本上，8 线程吞吐量从约 1000 万次读取/秒提高到 3000 万次以上，单次读取消耗的内核周期从约 2950降至 725。
- 后续第三版补丁在 64 线程 Threadripper 上，从 1330 万次读取/秒提高到 3.04 亿次，约为原来的 23 倍；LWN 的概括更保守，称读取密集型基准约快一个数量级。
- 这些属于合成基准，真实负载收益可能小得多。读取尚未映射的用户页会额外经历一次失败的页异常，单线程小块读取反而慢了五成以上；Linus 也列出了 10 项已知问题。
-
AI 生成的补丁仍需接受正常的人类评审。 评审者发现，在 folio 被替换且文件大小恰好扩展时，读者可能复制出从未写入的数据；Linus 认可问题并提出调整文件大小读取的时机。开发者还讨论了用页类型替代标记位的设计。视频叙述时，补丁尚未合并主线，仍需通过维护者审查。
-
Linus 的使用方式强调人负责方向、测试和验收。 据补丁说明，代码、测试程序、问题清单及评审邮件初稿由 Claude Code 在其指导下生成，性能测试在他自己的机器上运行。视频另举一例：LLM 帮助梳理旧代码，在确认已知问题之外，又发现了 3 个潜伏十余年的漏洞，最早可追溯到 2013 年的提交。
-
GCC 的“15 行红线”主要针对版权意义上的贡献。 按视频对政策的转述，约 15 行代码或文本可能达到需要处理版权归属的规模；具有法律意义、包含或源自 LLM 输出的贡献会被拒收，人工修改生成结果后再提交也不能绕过限制。这是项目政策中的判断尺度，不能理解为通用法律规定的精确行数门槛。
-
GCC 对辅助用途留有空间，并要求披露 AI 参与。 阅读代码、研究、找漏洞、报告问题和审查补丁均可使用 LLM；测试用例可由维护者酌情接受，小改动也可在明确标注后接收。AI 协助需添加
Assisted-by标记，Signed-off-by则必须由人签署。视频还提到，资深开发者 Jeff Law 实测 AI 辅助审查补丁时，认为约 两成输出有用。 -
GCC 的主要顾虑是版权链条与 GPL 的可执行性。 如果生成代码缺乏可主张的版权，未来项目可能难以依据 GPL 约束他人使用这些代码。视频以美国版权局强调人类作者贡献的立场说明这一担忧，同时指出 GCC 内部也有人批评政策过度聚焦法律，未充分解决维护者负担和长期可维护性。该政策会定期复审，视频提到下一次安排在 2027 年初。
-
团队可用两个维度判断 AI 贡献能否接收。 第一，生成内容是否会留在代码库中：辅助分析与生成实现代码带来的版权、维护责任不同，生成的测试代码也应纳入判断。第二，是否有人能解释设计、验证正确性并签字负责。视频的核心主张是：AI 可以参与开发，但提交者必须理解代码并承担责任。