Linux 6.19 调度器功能因性能回归而被禁用

今天，一个用于禁用 Linux 6.19 合并窗口期间重新实现的内核调度器 NEXT_BUDDY 功能的补丁已提交到 tip/tip.git 的”sched/urgent” Git 分支。该功能似乎导致了某些尚未得到其他解决的性能退化问题。

在 Linux 6.19 合并窗口期间，NEXT_BUDDY 功能在为 EEVDF 适配后重新引入。但该代码存在一些性能退化问题，因此”sched/urgent”分支中的补丁禁用了该功能…随着补丁提交到这个紧急的 TIP 分支，预计在接下来的几天内会作为调度器修复的一部分被主线性化。禁用 NEXT_BUDDY 的一行补丁解释如下：

“NEXT_BUDDY 在引入 EEVDF 时被禁用，并在通过提交 e837456fdca8 (“sched/fair: 重新实现 NEXT_BUDDY 以符合 EEVDF 目标”) 对 NEXT_BUDDY 进行 EEVDF 重写后再次启用。原本没有预料到这会是一个没有水晶球指令的普遍胜利，但即使也有报告称有所收益，这些报告的回归仍然是一个问题。具体来说；

o mysql 在客户端/服务器运行在不同的服务器上时出现回归
o specjbb 报告的峰值指标较低
o daytrader 出现性能退化

mysql 的情况比较现实，是一个需要关注的问题。需要确认 specjbb 是否只是将峰值性能的测量点转移了，但仍然是一个关注点。daytrader 被认为是具有代表性的实际工作负载。

目前无法访问测试机器来验证这个问题任何修复方案。暂时默认禁用 NEXT_BUDDY，直到根本原因得到解决。”

除了 MySQL、SPECjbb 和 DayTrader 的退化问题外，在我早期 Linux 6.19 基准测试中，早在 12 月初我也发现并警告了调度器退化问题——”调度器问题：在 Linux 6.19 中发现早期性能退化问题”。在该过程中，当回溯一个可测量的 Nginx HTTPS Web 服务器退化问题时，e837456fdca8 NEXT_BUDDY 提交最终成为该退化问题的可能原因之一。

我还没有完全分析所有回归问题，所以一旦这个补丁合并到 Linux 6.19 中，将很有趣重新审视以确认它是否解决了问题，以及这个特定提交可能影响了哪些其他工作负载。同时，正如补丁信息中提到的，NEXT_BUDDY 帮助提升了某些工作负载的性能，所以一旦这个补丁合并，与 v6.19 周期早期相比，性能可能会有一些下降。

转自 Linux 6.19 Scheduler Feature Being Disabled Due To Performance Regressions – Phoronix