这场性能事故的源头，要追溯到上个月 Linux 7.0 合并窗口期间引入的 SLUB “sheaves”（内存块捆绑）系列新特性。告别 SLAB 复杂锁争用？Linux 7.0 拟全面铺开 Sheaves 机制

由于 mempool 分配策略暴露出了不合理的捆绑重填（sheaf refill）限制，导致在具有持久跨 CPU 分配/释放模式的工作负载下，系统性能断崖式下跌。

最早发现并报告这一严重问题的是来自 Red Hat 的资深工程师 Ming Lei。他在邮件列表中详细描述了受灾情况：

“通过 815c8e35511d 提交合并的 SLUB 'sheaves' 系列代码，给具有持久跨 CPU 内存分配/释放模式的工作负载带来了严重的性能倒退。在 ublk 空目标平台（null target）基准测试中，IOPS 从 Linux 6.19 版本的约 3600 万，直接暴跌到了约 1300 万，降幅高达约 64%。”

更棘手的是，开发团队在尝试使用二分法（Bisecting）定位具体是哪行代码闯祸时，遇到了一次内核恐慌（Kernel panic，对应提交 17c38c88294d）。这导致精准定位第一个“坏提交（bad commit）”的排查工作一度受阻。

极限拉扯：SUSE 工程师紧急提交修复方案

为了挽救 Linux 7.0 的底层 I/O 性能，来自 SUSE 的 Linux 内核工程师 Vlastimil Babka 火速构思了一套修复方案。

该补丁的核心逻辑是：当系统不允许阻塞（blocking is not allowed）时，依然允许进行 sheaf 重填。虽然这波操作目前还没有将性能 100% 恢复到 6.19 时代的巅峰状态，但已经极大缓解了暴跌的窘境。据开发者透露，后续还会跟进另一个补丁，专门处理无内存节点（memory-less nodes）的潜在隐患，以期彻底根除性能衰退。

目前，这套被称为“救火队长”的分配器修复方案已经通过拉取请求（Pull request）提交，按照内核开发节奏，它会被火线合并，随即将包含在本周日发布的 Linux 7.0-rc3 候选版本内核中。

在这个容器化和高频高并发 I/O 满天飞的时代，底层分配器的一个小失误就能报销掉大半的物理盘性能。好在开源社区的响应速度依然顶尖，准备升级 7.0 内核的运维们，可以松一口气了。