Linux CPU 频率缩放

现代处理器公开了在执行能力、功耗和发热之间进行权衡的性能状态。Linux 通过 CPUFreq 提供这些控制。“频率”一词因兼容性仍保留在接口中，尽管硬件管理的 Intel HWP 和 AMD CPPC 操作的是性能请求，而不是离散的时钟表。

CPUFreq 的三个层次 #

CPUFreq 包括：

核心，拥有策略对象和通用 sysfs 接口。
调节器，将工作负载需求转换为性能请求。
缩放驱动程序，将请求转换为特定于平台的寄存器、固件或硬件操作。

一次只能注册一个 struct cpufreq_driver。因此，驱动程序必须处理所有 CPUFreq 可用的 CPU；异构系统仍然使用策略对象表示不同的控制域。

调度器驱动的 schedutil 调节器会在任务入队、出队和调度器时钟等事件上接收利用率更新。它推导容量请求，并直接调用驱动程序，或根据驱动程序是否支持快速转换而通过延迟工作调用。其他通用调节器包括 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 状态；选定的 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 状态（HWP，市场名称为 Speed Shift）时，硬件会在软件限制和能效偏好内选择性能。不使用 HWP 时，驱动程序根据调度器利用率回调运行其选择算法。
被动模式下，sysfs 报告 intel_cpufreq。schedutil 等通用调节器选择请求，而 intel_pstate 作为普通缩放驱动程序运行。

amd_pstate 使用 ACPI 协作处理器性能控制（CPPC），其抽象性能尺度比传统 ACPI P 状态表更细。

被动/引导操作与通用 CPUFreq 调节器配合，发送最小、最大和期望性能请求。
活动 EPP 操作在驱动程序文档中显示为 amd-pstate-epp，由平台支持的模式控制，使硬件能够更多地根据能效偏好选择性能。

如果平台缺少可用的 ACPI _CPC 描述，初始化可能回退到 acpi-cpufreq。当前模式选择和可用属性取决于正在运行的内核，因此应检查 sysfs，而不是从 CPU 供应商推断驱动程序。

加速、热限制和测量 #

加速表示允许使用高于标称可持续范围的性能；它不是保证的时钟。封装功耗限制、活动核心数、固件策略、温度和散热决定硬件是否能满足请求。全局 boost 控件可能出现在 /sys/devices/system/cpu/cpufreq/ 下，而 intel_pstate/no_turbo 和 AMD 特定驱动属性会在受支持系统上公开相关控制。

因此，CPUFreq 限制是受其他控制回路约束的请求。热冷却设备和固件可能将性能限制在请求值以下，空闲 CPU 也可以独立于 CPUFreq 进入睡眠状态。

测量时，应在一段时间内采样硬件反馈，而不是反复读取一个 sysfs 文件：