Linux CPU 頻率調整

現代處理器暴露在執行能力與功率、熱量之間取捨的效能狀態。Linux 透過 CPUFreq 提供這些控制。雖然硬體管理的 Intel HWP 與 AMD CPPC 是針對效能要求運作，而不是離散時脈表，「頻率」仍因相容性而保留在介面中。

CPUFreq 的三個層級 #

CPUFreq 包含：

核心，擁有原則物件與共用 sysfs 介面。
調節器，將工作負載需求轉為效能要求。
調整驅動程式，將要求轉譯為平台專用的暫存器、韌體或硬體作業。

一次只能註冊一個 struct cpufreq_driver。因此驅動程式必須處理 CPUFreq 可用的每個 CPU；異質系統仍使用原則物件表示不同的控制網域。

由排程器驅動的 schedutil 調節器會在工作排入、取出與排程器 tick 等事件上接收使用率更新。它推導容量要求，並直接呼叫驅動程式，或依驅動程式是否支援快速轉換而透過延後工作呼叫。其他一般調節器包括 performance、powersave、ondemand、conservative 與 userspace，但集合取決於核心設定與載入的模組。

原則表示硬體控制網域 #

struct cpufreq_policy 表示共用效能控制介面的邏輯 CPU。原則可以涵蓋一個邏輯 CPU，或多個無法獨立控制的 CPU。核心為每個 CPU 保留原則指標；同一硬體網域中的 CPU 指標會參照相同物件。

驅動程式初始化新原則時，其 ->init() 回呼提供：

相關 CPU 遮罩；
硬體最小與最大頻率；
硬體使用離散表時的運作頻率表；
轉換屬性與驅動程式能力。

核心接著附加調節器，並呼叫其 ->init() 與 ->start() 作業。啟動排程器感知的調節器會安裝每 CPU 使用率回呼。具有自身選擇演算法的驅動程式可以改為實作 ->setpolicy()，繞過一般調節器。CPU 熱插拔可在最後一個 CPU 離線時停用原則，稍後重新啟用，而不改變底層控制網域模型。

檢查與控制原則 #

每個原則都出現在 /sys/devices/system/cpu/cpufreq/policyX/。related_cpus 列出網域中的每個邏輯 CPU，包括離線 CPU；affected_cpus 列出其線上成員。

有用的屬性包括：

屬性	意義
`scaling_driver`	提供原則服務的已註冊驅動程式
`scaling_available_governors`	調節器，或作用中 `intel_pstate` 模式中的驅動程式演算法
`scaling_governor`	目前調節器或演算法；可寫入
`cpuinfo_min_freq`、`cpuinfo_max_freq`	以 kHz 為單位的硬體限制
`scaling_min_freq`、`scaling_max_freq`	以 kHz 為單位、可寫入的原則限制
`scaling_cur_freq`	驅動程式／核心回報或估算的目前原則頻率
`cpuinfo_cur_freq`	支援時，由硬體取得的目前頻率

scaling_cur_freq 不一定是瞬時測量值。在許多系統上它是最近要求的 P-state；選定的 x86 驅動程式可以提供更具代表性的值，但硬體可能在觀察之間改變效能。當驅動程式提供連續範圍時，scaling_available_frequencies 可能不存在。

變更前讀取原則：

bash

policy=/sys/devices/system/cpu/cpufreq/policy0
grep . "$policy"/{related_cpus,scaling_driver,scaling_available_governors,scaling_governor}
grep . "$policy"/{cpuinfo_min_freq,cpuinfo_max_freq,scaling_min_freq,scaling_max_freq}

echo schedutil | sudo tee "$policy/scaling_governor"
echo 1800000 | sudo tee "$policy/scaling_max_freq"

限制套用至整個原則，而不只是目錄名稱中的 CPU 編號。核心會拒絕高於最大值的最小值，以及低於最小值的最大值。

Intel 與 AMD P-State 驅動程式 #

intel_pstate 支援許多、但不是所有的 Sandy Bridge 與後續 Intel 處理器。驅動程式選擇並非無條件：硬體支援、韌體、核心設定與命令列選項可能導致另一驅動程式繫結。

在作用中模式中，sysfs 回報 intel_pstate。驅動程式提供 performance 與 powersave 演算法，而不是一般調節器。使用 Intel 硬體管理 P-state（HWP，市售名稱為 Speed Shift）時，硬體會在軟體限制與能效偏好提示內選擇效能。沒有 HWP 時，驅動程式會從排程器使用率回呼執行選擇演算法。
在被動模式中，sysfs 回報 intel_cpufreq。schedutil 等一般調節器選擇要求，而 intel_pstate 作為一般調整驅動程式運作。

amd_pstate 使用 ACPI 協作式處理器效能控制（CPPC），其抽象效能尺度比傳統 ACPI P-state 表更細緻。

被動／引導式操作與一般 CPUFreq 調節器配合，並傳送最小、最大與期望效能要求。
作用中 EPP 操作在驅動程式文件中顯示為 amd-pstate-epp，由平台支援的模式控制，讓硬體依能效偏好更大程度地進行選擇。

若平台缺少可用的 ACPI _CPC 描述，初始化可能退回 acpi-cpufreq。目前模式選擇與可用屬性取決於執行中的核心，因此請檢查 sysfs，而不要從 CPU 供應商推斷驅動程式。

Boost、熱限制與測量 #

Boost 是允許使用高於標稱可持續範圍的效能，不是保證的時脈。封裝功率限制、作用中核心數量、韌體原則、溫度與散熱決定硬體是否能履行要求。全域 boost 控制可能出現在 /sys/devices/system/cpu/cpufreq/ 下，而 intel_pstate/no_turbo 與 AMD 專用驅動程式屬性則在支援的系統上暴露相關控制。

因此 CPUFreq 限制是受到額外控制迴路約束的要求。散熱冷卻裝置與韌體可能將頻率降低至要求值以下，而閒置 CPU 可以獨立於 CPUFreq 進入睡眠狀態。

測量時，請在一段時間內取樣硬體回饋，而不要反覆讀取一個 sysfs 檔案：