一行代码提速80倍:Linux大神用AI挖出了潜伏的IO性能杀手
性能优化这事儿,有时候就像是在黑暗的房间里找开关。你可能摸索了几个星期一无所获,但一旦找对了地方,轻轻一按,整个世界瞬间就亮了。
最近 Linux 社区发生了一件挺有意思的事,堪称这种完美剧本。故事的主角是 Linux 块设备维护者、IO_uring 的核心开发者 Jens Axboe。而这次协助他打破僵局的竟然是 AI。
这件事的结果非常惊人:一个困扰许久的底层 I/O 问题被修复,性能直接暴涨了 50 到 80 倍。 而这一切的核心,仅仅是一行代码的改动。
诡异的 500 毫秒延迟
事情的起因是 Jens Axboe 在调试一些 I/O 性能问题。作为 IO_uring 的缔造者,他对 Linux 的存储子系统了如指掌。但在最近的一次调试中,他遇到了一个让他挠头的现象。
他在虚拟机环境中运行 io_uring 的回归测试时,发现了一个奇怪的规律:当使用 virtio-blk 或 NVMe 设备时,测试跑得飞快,通常一秒钟就能搞定。但一旦切换到 AHCI 设备,测试就会随机超时,甚至直接失败。
这种“随机性”是所有开发者的噩梦。它意味着问题不是每次都复现,而且很可能跟底层的时序或者中断处理有关。Jens 发现,在某些情况下,系统明明有 I/O 请求需要提交,但进程却莫名其妙地“睡”了过去。
这一睡就是 500 毫秒。
在计算机的世界里,500 毫秒简直就是半个世纪。对于追求极致吞吐的 IO_uring 来说,这完全是不可接受的。
当大神遇上 Claude
面对这个棘手的底层逻辑陷阱,Jens 做了一个挺时髦的决定:找 AI 聊聊。他并没有指望 AI 能直接丢给他一段完美的代码(事实证明 AI 甚至还差点闯了祸),而是希望 AI 能帮他理清复杂的代码逻辑。
他把自己编写的一个复现问题的脚本丢给了 Claude,让 AI 帮他分析其中的事件循环逻辑。
这一步其实非常关键。很多时候我们排查 bug,并不是因为不懂代码,而是因为陷入了思维定势。AI 的好处在于,它没有“定势”,它只会机械地、全面地分析所有可能的路径。
Claude 在分析过程中并非一帆风顺。据 Jens 在社交媒体上的吐槽,在调试过程中,Claude 给出的某些建议操作甚至导致他的虚拟机虚拟磁盘部分损坏。好在他技术过硬,最终还是救回来了。
但这点“小插曲”并没有掩盖 AI 的功劳。通过与 Claude 的交互,Jens 重新梳理了事件循环的各个环节,终于锁定了问题的真凶。
一行代码的威力
问题的核心出在 ppoll() 系统调用上。
在某些特定的空闲系统场景下,ppoll() 会错误地进入休眠状态,等待时间长达 499 毫秒甚至更久,而此时队列里其实是有 I/O 请求等着被提交的。这就好比快递员明明手里拿着包裹,却在楼下傻站了半分钟才上楼。
找到病灶后,修复方案简直简单得令人发指。
Jens 提交的补丁主要就改动了一行实际的逻辑代码(外加几行注释)。但这行代码的作用却是立竿见影的。它避免了 ppoll() 在不该睡觉的时候睡觉,确保存储请求能被即时处理。
效果如何?
根据 Jens 的测试,在打上这个补丁后,相关场景下的 IO_uring 性能直接提升了 50 到 80 倍。这已经不是“优化”了,这简直就是从自行车换成了火箭。
技术的本质是做减法
这修补目前已经进入了 QEMU 的代码合并流程。
这个故事给我们最大的启示,或许并不是 AI 有多神,而是底层系统的复杂性往往超乎想象。即便是 Jens Axboe 这样的顶级专家,在面对数十年积累下来的内核代码山时,也难免会有“只缘身在此山中”的困惑。
AI 在这里扮演的,更像是一个不知疲倦的“橡皮鸭调试法”对象。它不需要懂什么是 NVMe 协议,它只需要告诉你:嘿,这段逻辑好像有点不对劲。
更有趣的是,这次巨大的性能飞跃,并没有依赖什么复杂的算法升级或者硬件换代,仅仅是移除了一块“绊脚石”。
在技术领域,增加功能往往容易,但准确地找到并移除那些拖后腿的“陈年旧账”,才是最考验功力的。而这 500 毫秒的延迟消除,对于未来数以亿计运行在 Linux 上的 I/O 操作来说,节省下来的时间将是天文数字。
下次当你觉得代码跑得慢时,不妨想一想,是不是也有个类似 ppoll() 的家伙,正在角落里偷偷睡觉呢?
信息来源:
- • https://lore.kernel.org/qemu-devel/20260213143225.161043-2-axboe@kernel.dk/
- • https://lore.kernel.org/qemu-devel/20260213143225.161043-1-axboe@kernel.dk/
- • https://www.phoronix.com/news/AI-50-80x-IO-uring