这并不是经常听到Linus Torvalds自己对Linux内核的性能退化发出警钟，但这发生在今天晚上正在进行的Linux 6.8合并窗口。Torvalds的AMD Ryzen线程裂解器系统突然遭受了更长的构建时间，至少是这个内核的新代码的结果。
今晚引起我注意的是 此消息由Linus Torvalds在一次“可怕的性能回归”上写的，并为Linux6.8编写了代码。他指出：
请注意，我目前正一分为二地参与这次合并，以实现可怕的业绩回归。
它使我的空内核构建从22秒缩短到44秒，并且使完整的内核构建变得非常慢。
我还没有完成对分，但它现在就在这个拉动中，所以我已经可以说我要在这里恢复一些东西，因为这让我的合并窗口变得很糟糕。
你已经被警告过了，
莱纳斯
这是对Linux 6.8的调度程序更改。对于像代码编译速度减半这样的工作负载的倒退来说，这是相当令人惊讶的，因为尽管Linux内核缺乏通用和健壮的持续集成(CI)，但负责这些更改的内核开发人员似乎会注意到如此戏剧性的变化……尤其是如果代码已经通过了Linux-Next等。
不久前，他增列：
我想结果应该不会令人惊讶
9c0b4bb7f6303c9c4e2e34984c46f5a86478f84d是第一个错误提交
但为了干净利落地恢复，我必须恢复所有
B3edde44e5d4(“cpufreq/schedutil：使用固定参考频率”)
F12560779f9d(“sched/cpufreq：Rework iowait Boost”)
9c0b4bb7f630(“sched/cpufreq：Rework Schedutil调速器性能评估”)这是一个32核（64线程）AMD锐龙Threadripper 3970X，fwiw。
我暂时会将该恢复保存在我的私有测试树中(这样我就可以再次拥有一台工作的机器)，但我会很快将它移到我的主分支，除非有人有快速解决此问题的方法。
从这条信息中，有趣的是看到莱纳斯·托瓦尔兹仍然在摇摆AMD Ryzen Threadriper 3970X工作站。回到2020年托瓦尔兹改用开线器在使用英特尔系统15年以上之后。令人有点惊讶的是，近四年后，考虑到现在可以获得的更快的性能，特别是与Ryzen Threadriper 7000系列系统一起使用，他仍然依赖ThreadRipper 3970X主力系统。无论如何，这种回归似乎是由于CPUFreq Schedutil州长的回归。
CPUFreq schedutil governor performance estimation rework由Linaro编写，旨在处理uclamp限制。但似乎里面有什么东西引起了问题。截至发稿时，托沃兹还没有就此事做出其他回应或发出其他信息。
But at least with this being spotted early and by Torvalds himself and with still over a week to go until Linux 6.8-rc1, it will hopefully be sorted out in short order and well before the Linux 6.8 stable release due out in March.
