Linux CPU 周波数スケーリング

現代のプロセッサーは、実行能力と電力・発熱を交換するパフォーマンス状態を公開します。 Linux は CPUFreq を通じてその制御を提供します。ハードウェア管理の Intel HWP と AMD CPPC が離散的なクロックテーブルではなくパフォーマンス要求で動作する場合でも、 互換性のためインターフェイスには「周波数」が残っています。

CPUFreq の 3 層 #

CPUFreq は次で構成されます。

1. ポリシーオブジェクトと共通 sysfs インターフェイスを所有する コア。
2. ワークロード要求をパフォーマンス要求へ変換する ガバナー。
3. 要求をプラットフォーム固有のレジスター、ファームウェア、ハードウェア操作へ変換する スケーリングドライバー。

一度に登録できる struct cpufreq_driver は 1 つだけです。そのためドライバーは CPUFreq が利用可能なすべての CPU を処理しなければなりません。異種システムでも、 ポリシーオブジェクトを使って異なる制御ドメインを表します。

スケジューラー駆動の schedutil ガバナーは、タスクの enqueue、dequeue、スケジューラー ティックなどのイベントで利用率更新を受け取ります。容量要求を導出し、ドライバーが 高速遷移をサポートするかに応じて、直接または遅延作業を通じてドライバーを呼び出します。 その他の汎用ガバナーには performance、powersave、ondemand、conservative、 userspace がありますが、利用可能な集合はカーネル設定とロード済みモジュールに 依存します。

ポリシーはハードウェア制御ドメインを表す #

struct cpufreq_policy はパフォーマンス制御インターフェイスを共有する論理 CPU を 表します。ポリシーは 1 つの論理 CPU、または独立制御できない複数 CPU を対象にできます。 コアは各 CPU にポリシーポインターを保持し、1 つのハードウェアドメインに属する CPU のポインターは同じオブジェクトを参照します。

ドライバーが新しいポリシーを初期化するとき、->init() コールバックは次を提供します。

• 関連 CPU マスク。
• ハードウェアの最小・最大周波数。
• ハードウェアが離散テーブルを使う場合の動作周波数テーブル。
• 遷移プロパティとドライバー能力。

その後コアはガバナーを接続し、その ->init() と ->start() 操作を呼び出します。 スケジューラー対応ガバナーの開始により、CPU ごとの利用率コールバックが登録されます。 独自の選択アルゴリズムを持つドライバーは、代わりに ->setpolicy() を実装して 汎用ガバナーを迂回できます。CPU hotplug は最後の CPU が offline になるとポリシーを 無効化し、基盤の制御ドメインモデルを変えずに後で再有効化できます。

ポリシーの検査と制御 #

各ポリシーは /sys/devices/system/cpu/cpufreq/policyX/ に現れます。related_cpus は offline CPU を含むドメイン内のすべての論理 CPU を列挙し、affected_cpus は online のメンバーを列挙します。

有用な属性には次があります。

scaling_cur_freq は必ずしも瞬間的な測定値ではありません。多くのシステムでは最後 に要求された P-state です。一部の x86 ドライバーはより代表的な値を提供できますが、 観測の間にハードウェアが性能を変更することがあります。ドライバーが連続範囲を公開 する場合、scaling_available_frequencies は存在しないことがあります。

変更前にポリシーを読み取ります。

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 supports many, but not every, Sandy Bridge and later Intel processor. Driver selection is not unconditional: hardware support, firmware, kernel configuration, and command-line options can cause another driver to bind.

• In active mode, sysfs reports intel_pstate. The driver supplies performance and powersave algorithms instead of generic governors. With Intel Hardware-Managed P-states (HWP, marketed as Speed Shift), hardware selects performance within software limits and energy-performance hints. Without HWP, the driver runs its selection algorithm from scheduler utilization callbacks.
• In passive mode, sysfs reports intel_cpufreq. Generic governors such as schedutil choose requests, and intel_pstate acts as a regular scaling driver.

amd_pstate uses ACPI Collaborative Processor Performance Control (CPPC), whose abstract performance scale is finer-grained than legacy ACPI P-state tables.

• Passive/guided operation works with generic CPUFreq governors and sends minimum, maximum, and desired performance requests.
• Active EPP operation, shown as amd-pstate-epp in driver documentation and controlled by the platform’s supported mode, lets hardware make more of the selection based on an Energy Performance Preference.

If the platform lacks a usable ACPI _CPC description, initialization can fall back to acpi-cpufreq. Current mode selection and available attributes depend on the running kernel, so inspect sysfs rather than inferring the driver from the CPU vendor.

Boost, Thermal Limits, and Measurement #

Boost is permission to use performance above the nominal sustainable range; it is not a guaranteed clock. Package power limits, active-core count, firmware policy, temperature, and cooling determine whether hardware can honor the request. Global boost controls may appear under /sys/devices/system/cpu/cpufreq/, while intel_pstate/no_turbo and driver-specific AMD attributes expose related controls on supported systems.

CPUFreq limits are therefore requests bounded by additional control loops. Thermal cooling devices and firmware can throttle below a requested value, and idle CPUs can enter sleep states independently of CPUFreq.

For measurement, sample hardware feedback over an interval instead of repeatedly reading one sysfs file:

turbostat --interval 1
perf stat -a -e msr/aperf/,msr/mperf/ -- sleep 5

APERF/MPERF-based tools estimate delivered average frequency while a CPU is active. Combine frequency with workload throughput, package power, and thermal data because a higher reported clock does not alone establish higher useful performance.

References #

• Kernel Documentation: CPU Performance Scaling
• Kernel Documentation: intel_pstate
• Kernel Documentation: amd-pstate