Claude辅助Linux页缓存优化：23倍基准、RCU边界与新RFC
10月19日，一份基于Linus Torvalds此前页缓存实验的重写RFC受到关注。原实验借助Claude Code协助开发，在64线程重复读取同一16字节热点时测得约23倍吞吐；新方案则把适用范围、RCU读侧安全和内存回收边界重新梳理。本文聚焦：这个数字测量了什么，以及为什么性能优化仍需要并发正确性证据。
如果你正在用 Claude Code、Codex 写程序，这件事比“AI 会不会取代程序员”的口号更有用。它展示了一段代码从“跑得快”走向“有机会被信任”时，还缺哪些证据。
Linus Torvalds（台上左侧）2024 年开源峰会资料照片；Pietro Lombardo 摄，Wikimedia Commons，CC0。此图并非本次补丁讨论现场。
先看清楚：23倍究竟是哪项成绩
问题出在 Linux 的页缓存。把文件的一部分先留在内存里，下次读取就不必每次找磁盘。多个处理器同时反复读同一小块数据时，系统原来会不停更新这块内存的引用计数，好像一群人每翻一次同一本资料，都要挤到一个柜台登记和注销。柜台成了瓶颈，文件本身却早已在内存里。
Linus 让 Claude Code 协助写代码、测试程序、审查与说明文字，并在公开邮件中明确说是在他的指导下完成。思路是：对于足够“热”的缓存页，读者先在一段受保护的时间里复制数据；即使页面准备被回收，也等这段时间结束再真正释放。这样可以少碰那个挤满人的引用计数柜台。
他公开的数字很醒目：在一台 Ryzen Threadripper 机器上，64 个线程反复从同一个位置读取 16 字节，吞吐从每秒约1330 万次升到约3.04 亿次，约为 23 倍。这是同一热点上的特定合成测试。Linus 本人随即强调，真实负载的收益会小得多。把它写成“Linux 全面快 23 倍”，会把测试条件抹掉。
原创数据图；数值取自 Linus 的内核邮件，64 线程、重复小块读取，不能代表日常电脑整体速度。
为什么“跑得快”还不等于“能上线”
旧流程虽然拥挤，却有一个容易理解的安全含义：读文件的人借用了缓存页，页面不能在他手里突然消失。新流程少做登记，就必须回答另一个问题：当页面被替换、文件大小变化、内存紧张时，读到的还是原来那份数据吗？
内核开发者在先前版本的讨论中指出过竞态：两个动作顺序只要刚好撞在一起，就可能读到不应暴露的内容。另一项测试也发现，延迟释放的页面在内存紧张时可能堆积，甚至触发意外的内存不足。它们不证明“Claude 写的代码全错”，但清楚说明速度曲线不能代替正确性证明。
10 月 19 日的新进展，正是 Meta 工程师 Kiryl Shutsemau 基于此前方案提交了重写的 RFC，也就是请社区讨论的草案。他把快速路径限定在已经变热、状态合适的页面，让冷数据仍走旧路；相关页面只有等读者结束后才释放。同时，他对内存回收、异常页面等情况补上处理，并在 EXT4、TMPFS、XFS 等场景做了测试。Phoronix 报道了这轮测试，Linux 内核邮件列表是原始讨论入口。这仍是待审草案，不是已经装进所有 Linux 电脑的正式更新。
这里有一个很实在的取舍：延迟释放页面能保护正在读取的数据，却也会让部分内存在短时间内不能重新分配。新方案只让热点页面进入快车道，并补上回收时的处理，正是在追求吞吐的同时限制这笔“内存欠账”。因此，评估结果不能只看每秒读取次数，还要看内存压力、回收过程以及不同文件系统下是否出现退化。公开测试给出了积极信号，尚不足以替代所有机器和负载上的审查。
这条时间线也纠正了一个容易误读的标题：最新进展不能简单算成“Claude 又独自把内核优化一次”。Linus 的实验提供了起点；发现边界、重写、扩充测试和后续审查都有人的参与。公开材料也没有证明 Kiryl 的改动完全没用 AI，因此不应反过来武断地写成“全靠人、AI 毫无作用”。
普通开发者能照着做什么
不必开发内核，也能把这个案例用到自己的 AI 编程工作中。假设你让 Claude Code 优化一个多人同时读取的服务，先把要求写成可检验的问题：哪些请求慢？是在读取同一份数据，还是网络、磁盘、数据库各自造成等待？让工具先提出假设和最小改动，再列出它预计会改善和可能会变差的场景。
第二步，同条件测前后。保留同一机器、同一输入、并发数、缓存状态和原版本，记录吞吐与延迟，而不是只截一张“最快的一次”。Linus 的 23 倍之所以可以讨论，恰恰因为公开了“64 线程反复读 16 字节”这个狭窄条件；如果换成单线程、大文件或频繁换数据，不能把旧数字直接搬过去。
第三步，主动找反例。这个补丁对应的反例不是抽象的“注意安全”，而是文件被截断或扩展、缓存页被替换、内存回收赶上读取等同时发生的情况。一般业务系统也有同类问题：订单修改碰上退款、重试碰上重复扣款、缓存失效碰上并发查询。让 AI 列边界可以加快排查，但测试设计和结果判断仍要对照真实系统约束。
最后留回退路径。先在小范围负载里观察，确认正确性和资源开销，再考虑上线。若优化只在刻意制造的热点里好看，其他场景反而变慢，就该收窄适用范围，甚至撤回。这也是新 RFC 仍在讨论而没有直接合入主线的原因之一：更广泛的验证尚未完成。
原创流程示意；对应本次补丁的热点限制、竞态与内存回收问题。
这件事真正改变了什么
AI 编程工具能把试错前移：原来迟迟没解决的性能问题，现在可以更快形成可运行的方案。但它也让“能跑出漂亮数字”的草案来得更快，审查负担不会自动消失。对个人开发者而言，价值不在于把生成代码的行数写进简历，而在于拿得出“问题、测试条件、边界、修正”这一整条证据链。
代码生成得越快，解释它为什么可靠的能力越值钱。
你若正在用 Claude Code 或 Codex，可以从一个低风险的真实瓶颈开始：先固定基线，再让工具提出改动，最后自己寻找最可能推翻结果的边界。这里会持续追踪热门 AI 工具的真实案例，讲清它们在什么条件下有用、又在哪里需要人把关。
你会把“AI 写出提速补丁”算作 AI 的成绩，还是更看重后续的人类审查与重写？
资料来源
- Linux 内核邮件列表：Linus Torvalds, “Improve page refcount scalability”, 2026-10-13，https://lkml.iu.edu/2610.1/13146.html
- Linux 内核源码提交：Linus Torvalds, “mm: read from the page cache without folio references”, 2026-10-10，https://mirrors.hust.edu.cn/git/linux.git/commit/?h=noref-filemap-read-with-llm&id=4c0f3697118eb3a708ea79175f7f07c43339bfab
- Phoronix：Michael Larabel, “Linus Torvalds’ AI Code Improved: Huge Performance Wins With Reworked Code”, 2026-10-19，https://www.phoronix.com/news/Reading-Page-Cache-WO-Folio-Ref
- freenode： “Linux RFC lets hot page-cache reads skip folio refcounts”, 2026-10-19，https://freenode.net/article/linux-rfc-lets-hot-page-cache-reads-skip-folio-refcounts
