頻率縮放調節器擴展了太多核心
我有兩台機器執行相同的作業系統、相同的核心、相同的 CPU 頻率縮放驅動程序和相同的 CPU 頻率縮放調節器。
如果一個程序固定一個核心，一個將提升所有核心頻率。
如果有一個程序固定一個核心，則一個只會提升一個物理核心。
機器A
CPU: Intel(R) Xeon(R) W-2140B CPU @ 3.20GHz Scaling driver: intel_pstate Scaling governor: powersave OS: Ubuntu 21.10 Kernel: 5.13.0-22-generic機器 B
CPU: 11th Gen Intel(R) Core(TM) i5-11600K @ 3.90GHz Scaling driver: intel_pstate Scaling governor: powersave OS: Ubuntu 21.10 Kernel: 5.13.0-22-generic觀察這些例子：
在機器 A 上固定兩個核心：（請注意，這台機器具有超執行緒，因此可擴展 16 個可用虛擬核心中的 4 個。）
在機器 B 上固定兩個核心：（請注意，這台機器有 6 個帶 HT 的核心，並且可以擴展所有 12 個虛擬核心。）
螢幕截圖是我自己編寫的一個開源頻率監視器freqtop 。橙色刻度顯示每個核心上的負載，定義為使用者+核心週期相對於總週期（使用者+核心+空閒）的百分比。
為什麼 i5-11600K CPU 會加速所有核心，即使只需要一個核心？
**更新：**我發現機器之間的一個區別是 pstate 的數量。
因為至強
/sys/devices/system/cpu/intel_pstate設置為33，而corei5設置為42。我不確定這有什麼意義。
我已經能夠讓 corei5 機器表現得更合適，並且只增加我們實際工作的核心的頻率。
為此，我發現我必須切換 intel_pstate 驅動程序模式。
在
/sys/devices/system/cpu/intel_pstate/status您可以在主動和被動模式之間切換。主動模式： 在這種模式下，驅動程序繞過 CPUFreq 的縮放調控器層，並為 P 狀態選擇提供自己的縮放算法。
被動模式： …驅動程序的行為類似於正常 CPUFreq 縮放驅動程序。也就是說，當需要與硬體對話以更改 CPU 的 P 狀態時，它由通用縮放調控器呼叫…
如果我沒看錯的話，我認為在活動模式下，CPU 來自作業系統本身的回饋較少。我認為 CPU 錯誤地猜測所有核心都需要節流。
仍然無法解釋的是，Xeon CPU使用相同的 intel_pstate 驅動程序在**主動移動中表現良好。**但這可能只是對並非所有 CPU 都相同的猜測。或者甚至可能是沒有正確執行 pstates 的可疑主機板或 BIOS。
在 Intel CPU 中，有幾種不同的方式來處理核心限制。全部學習它們是非常技術性的。大多數人只是學習他們使用的 CPU。但我確信是韌體（BIOS、UEFI）和/或處理器內部允許的控制級別為您提供了這些不同的結果。
我在我們的兩台機器上看到了相同的情況，它們都執行 Debian Bullseye，但處理器不同。有時
$ powertop可以揭示。它旨在調整筆記型電腦的功耗，但由於不同的原因，台式機上顯示的資訊很有趣。我使用 powertop 檢查核心是否在 turbo 模式下執行，以及它們的節流程度等等。它也適用於 AMD。
你已經寫了那個監視器，所以看起來你可能比我知道的更多。
這個論壇不是討論很多細節的地方，僅僅是因為材料太龐大和技術性太強。我希望這有幫助。