Linux CPUFreq 子系统完全指南CPU 性能缩放的架构、sysfs 接口与调频策略解析【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux本文基于 Linux 内核源码树中的 Documentation/admin-guide/pm/cpufreq.rst 编写。该文档详细阐述了内核 CPUFreqCPU 频率缩放子系统的概念、三层架构、policy 对象模型、CPU 初始化流程、sysfs 用户空间接口、六大通用调频 governor 以及频率 Boost 机制。读完本文你将能够理解 P-state 与 CPU 性能缩放的权衡本质掌握CPUFreq核心、scaling governor、scaling driver 三层代码的职责划分与协作关系熟练操作/sys/devices/system/cpu/cpufreq/policyX/下的全部属性依据负载特征为不同场景选择并调优performance、schedutil、ondemand、conservative等 governor以及通过boost控制旋钮管理 Turbo Boost / Core Performance Boost 等频率提升功能。一、CPU 性能缩放CPU Performance Scaling的基本概念大多数现代处理器都能运行在多种不同的时钟频率与电压组合之下这些组合常被称为工作性能点Operating Performance Points在 ACPI 术语中则称为P-state。一般来说时钟频率与电压越高CPU 在单位时间内可以退休retire的指令数就越多即 CPU 容量越大但频率与电压越高CPU 在单位时间内消耗的能量即功耗也越大。因此在 CPU 容量单位时间可执行的指令数与功耗之间存在天然的权衡tradeoff。某些场景下我们希望程序跑得越快越好此时没有理由使用除最高 P-state最高性能的频率/电压组合以外的任何状态而在另一些场景下我们可能并不需要那么高的执行速度——长期维持最高 CPU 容量却用不满它会被视为一种浪费此外受散热能力、电源供电容量等物理限制也不可能长时间维持最大 CPU 容量。为了覆盖这些情况硬件提供了允许 CPU 在不同频率/电压配置P-state之间切换的接口。这些接口通常配合估算所需 CPU 容量的算法一起使用由算法决定将 CPU 置于哪个 P-state。由于系统利用率会随时间不断变化这一决策过程需要周期性反复执行。这项活动被称为CPU performance scaling或CPU frequency scaling因为它涉及调整 CPU 时钟频率。二、Linux 中的 CPUFreq 子系统三层代码架构Linux 内核通过CPUFreqCPU Frequency scaling子系统支持 CPU 性能缩放。该子系统由三层代码构成core核心、scaling governors调频策略与 scaling drivers调频驱动。层职责说明CPUFreqcore提供通用代码基础设施与用户空间接口定义其他组件运行的基本框架对所有支持性能缩放的平台通用Scaling governors实现估算所需 CPU 容量的算法每个 governor 实现一个可能是参数化的缩放算法Scaling drivers与硬件打交道向 governor 提供可用 P-state或 P-state 范围的信息并通过平台相关的硬件接口按 governor 的请求改变 CPU P-state三层之间的解耦设计原则上所有可用的 scaling governor 都可以与任意 scaling driver 搭配使用。这一设计基于如下观察——大多数情况下P-state 选择算法所需的信息都可以用**平台无关platform-independent**的形式表示因此同一套调频算法应当适用于所有受支持的平台。不过这一观察并非对任何算法都成立如果缩放算法依赖于硬件自身提供的信息例如通过反馈寄存器获取的数据那么这些信息通常是特定于其来源硬件接口的难以用抽象、平台无关的方式表达。为此CPUFreq允许 scaling driver绕过 governor 层并实现自己的性能缩放算法。最典型的例子就是 intel_pstate 驱动。三、CPUFreq 策略对象struct cpufreq_policy在某些情况下P-state 控制的硬件接口会被多个 CPU共享。例如同一个寄存器或一组寄存器被用来同时控制多个 CPU 的 P-state写入它会影响所有这些 CPU。CPUFreq用struct cpufreq_policy 对象来表示共享硬件 P-state 控制接口的 CPU 集合即使某组只有一个 CPU为保持一致也会使用 policy 对象。CPUFreq核心为系统中每一个 CPU包括当前离线的 CPU维护一个指向 policy 对象的指针。若多个 CPU 共享同一硬件 P-state 控制接口它们对应的指针都指向同一个 policy 对象。从源码看include/linux/cpufreq.h 中的 struct cpufreq_policy 至少包含以下几类关键成员与本文档所述概念一一对应CPU 集合掩码cpus仅在线 CPU、related_cpus在线 离线 CPU、real_cpus相关且 present 的 CPU、shared_typeACPI 中受影响的 CPU 应如何协调频率范围min、max单位 kHz、cur当前频率仅在 governor 模式下需要、suspend_freq挂起期间设置的频率、cpuinfocpufreq_cpuinfo结构内含硬件支持的max_freq、min_freq与以纳秒为单位的transition_latencygovernor 相关governor当前附着的 governor 指针、governor_data、last_governor上次使用的 governor 名频率表freq_tablecpufreq_frequency_table当支持的 P-state 不是连续区间时使用与freq_table_sorted排序状态QoS 约束constraints、min_freq_req、max_freq_req、boost_freq_req基于 freq_qos 框架的约束请求快速切换支持fast_switch_possible由 driver 设置表示可在共享该 policy 的任意 CPU 上改变频率且影响所有 policy CPU、fast_switch_enabled由支持快速切换的 governor 借助cpufreq_enable_fast_switch()设置并发保护rwsem读写信号量——读取 policy 结构的例程对其做 down_read而写入或可能移除 policy 的例程如 CPU 热插拔在做任何操作前须持有写锁。CPUFreq将 struct cpufreq_policy 作为其基本数据类型其用户空间接口的设计也建立在 policy 概念之上。四、CPU 初始化流程driver 注册、policy 创建与 governor 附着4.1 scaling driver 的注册要让CPUFreq工作首先必须注册一个 scaling driver。同一时间只能注册一个 scaling driver因此该 driver 必须能够处理系统中的所有 CPU。driver 可以在 CPU 注册之前或之后注册若 CPU 先注册则在 scaling driver 注册时driver core 会调用CPUFreqcore 记录所有已注册的 CPU若 scaling driver 先注册那么之后每个 CPU 注册时CPUFreqcore 都会在注册时刻被调用来记录该 CPU。无论哪种顺序只要CPUFreqcore 准备好处理某个它尚未见过的逻辑 CPU就会立即被调用来记录它。需要说明的是这里的逻辑 CPU既可能是物理单核处理器也可能是多核处理器中的单个核还可能是物理处理器或处理器核中的一个硬件线程hardware thread。本文下文除非特别说明CPU均指逻辑 CPUprocessor指可能包含多个逻辑 CPU 的物理部分。4.2 policy 对象的创建与初始化CPUFreqcore 被调用后会检查给定 CPU 的 policy 指针是否已设置若已设置则跳过 policy 创建否则创建一个新的 policy 对象并初始化这包括在 sysfs 中创建新的 policy 目录并将该 CPU 对应的 policy 指针指向新对象的内存地址。随后scaling driver 的-init()回调以新 CPU 的 policy 指针为参数被调用。该回调负责初始化给定 CPU更准确地说是它所属的、由 policy 对象表示的共享硬件接口的 CPU 集合的性能缩放硬件接口若调用它的 policy 对象是新建的则设置该 policy 的参数例如硬件支持的最小/最大频率、可用频率表当支持的 P-state 集合不是连续区间时、以及属于同一 policy 的 CPU 掩码同时包含在线与离线 CPU。该掩码随后被 core 用来填充集合内所有 CPU 的 policy 指针。4.3 scaling governor 的附着与启动新建 policy 对象的下一个主要初始化步骤是为其附着 scaling governor初始时是内核命令行或配置决定的默认 governor之后可通过 sysfs 更改。流程如下将新 policy 对象的指针传给 governor 的-init()回调初始化处理该 policy 所需的全部数据结构并可能为它添加 governor 的 sysfs 接口通过调用 governor 的-start()回调启动它。-start()回调需要为 policy 内所有在线 CPU 向CPU 调度器CPU scheduler注册每-CPU 利用率更新回调per-CPU utilization update callbacks。调度器会在重要事件如任务入队/出队、每个调度器 tick 迭代或任何 CPU 利用率可能发生变化从调度器视角看时调用这些回调。回调负责执行确定该 policy 接下来应使用哪个 P-state 所需的计算并按 P-state 选择结果调用 scaling driver 修改硬件。scaling driver 可能被直接从调度器上下文调用也可能通过内核线程或工作队列异步调用具体取决于 driver 与 governor 的配置和能力。4.4 非新建 policy 与 CPU 热插拔场景对于非新建但此前处于inactive状态其所有 CPU 均离线的 policy 对象会采取类似的步骤。唯一的实际区别是CPUFreqcore 会尝试使用该 policy 变为 inactive 之前使用的 governor而非默认 governor。若一个此前离线的 CPU 被重新上线但与其共享 policy 的其他 CPU 已在线则无需重新初始化 policy 对象只需重启 scaling governor 使其纳入新上线的 CPU 即可——具体做法是依次调用该 policy 的-stop与-start()回调。4.5 intel_pstate 的特殊路径如前所述intel_pstate scaling driver 绕过CPUFreq的 governor 层并提供自己的 P-state 选择算法。因此使用 intel_pstate 时新 policy 对象不会附着 scaling governor而是调用 driver 的-setpolicy()回调为每个 policy 注册每-CPU 利用率更新回调。这些回调被 CPU 调度器以与 scaling governor 相同的方式调用但在 intel_pstate 场景下它们在调度器上下文中一步完成P-state 决策与硬件配置更改。policy 对象及相关数据结构会在 scaling driver 被注销时例如其内核模块被卸载或该 policy 最后一个 CPU 被注销时被销毁。在 drivers/cpufreq/cpufreq.c 中可以看到核心的cpufreq_online()函数它通过 CPU 热插拔回调cpuhp_cpufreq_online见 drivers/cpufreq/cpufreq.c与 CPU 设备子系统接口cpufreq_add_dev两条路径被触发从而覆盖CPU 先注册与driver 先注册两种时序。五、sysfs 中的 policy 接口用户空间控制面在内核初始化期间CPUFreqcore 会在/sys/devices/system/cpu/下创建一个名为cpufreq的 sysfs 目录kobject。该目录为 core 维护的每个 policy 对象包含一个policyX子目录X为整数编号。/sys/devices/system/cpu/cpuY/下的cpufreq符号链接指向这些 policyX 目录供该 policy 关联或属于的所有 CPU 使用。/sys/devices/system/cpu/cpufreq/policyX/目录中的属性文件用于控制对应 policy 对象即与其关联的所有 CPU的CPUFreq行为。其中一部分属性是通用generic属性由CPUFreqcore 创建其行为一般不依赖正在使用的 scaling driver 和附着的 governor某些 scaling driver 还会在 policy 目录中添加driver 专有属性以控制 driver 行为中与 policy 相关的部分。从源码看通用属性在 drivers/cpufreq/cpufreq.c 中通过cpufreq_freq_attr_ro()/cpufreq_freq_attr_rw()宏声明并统一注册到cpufreq_attrs[]属性数组中drivers/cpufreq/cpufreq.c。下表完整列出CPUFreqcore 提供的通用属性属性读写性含义affected_cpus只读属于该 policy 的在线CPU 列表即共享该 policyX 对象所代表硬件性能缩放接口的 CPUbios_limit只读若平台固件BIOS要求 OS 对 CPU 频率施加上限则该上限通过此属性报告若存在。该上限可能源于某些常为无意的BIOS 设置、服务处理器或其他 BIOS/HW 机制的限制。注意不覆盖ACPI 热限制那可以通过通用 thermal 驱动发现。若当前 scaling driver 不支持则不存在cpuinfo_cur_freq只读权限 0400从硬件获取的该 policy 内 CPU 的当前频率kHz预期是硬件实际运行的频率若无法确定则不应存在cpuinfo_avg_freq只读该 policy 内所有 CPU 的平均频率kHz由硬件提供的反馈导出时间窗口最多几毫秒。需要专门硬件支持如 ARM 上的 AMU 扩展若无法确定则不应存在。注意对给定 CPU 获取当前频率失败会返回相应错误例如对保持空闲的 CPU 返回 EAGAIN在 ARM 上触发cpuinfo_max_freq只读该 policy 内 CPU 可以运行的最高频率kHzcpuinfo_min_freq只读该 policy 内 CPU 可以运行的最低频率kHzcpuinfo_transition_latency只读该 policy 内 CPU 从一个 P-state 切换到另一个所需的时间纳秒related_cpus只读属于该 policy 的所有在线与离线CPU 列表scaling_available_frequencies只读该 policy 内 CPU 的可用频率列表kHzscaling_available_governors只读内核中存在的、可附着到该 policy 的CPUFreqscaling governor 列表若使用 intel_pstate 驱动则为该驱动可应用于该 policy 的缩放算法列表。注意部分 governor 是模块化的需要加载相应内核模块后才会出现在此列表中scaling_cur_freq只读该 policy 内所有 CPU 的当前频率kHz。多数情况下这是 scaling driver 通过其缩放接口向硬件请求的最后一个 P-state 的频率可能未必反映 CPU 实际运行频率受硬件设计等限制。某些架构如 x86可能尝试通过此属性提供更精确反映当前频率的信息但即便如此也可能不是硬件此刻看到的精确频率该行为仅在启用CPUFREQ_ARCH_CUR_FREQ宏选项时可用scaling_driver只读当前使用的 scaling driverscaling_governor读写当前附着到该 policy 的 scaling governor若使用 intel_pstate 驱动则为当前应用的驱动缩放算法。写入它会使新的 governor 被附着或新的算法被应用写入的字符串必须是scaling_available_governors所列名称之一scaling_max_freq读写允许该 policy 内 CPU 运行的最高频率kHz。写入表示整数的字符串会设置新上限不得低于scaling_min_freq的值scaling_min_freq读写允许该 policy 内 CPU 运行的最低频率kHz。写入表示非负整数的字符串会设置新下限不得高于scaling_max_freq的值scaling_setspeed读写仅当userspacegovernor 附着到该 policy 时才有效。读取返回 governor 最后一次请求的频率kHz写入可设置该 policy 的新频率六、通用 Scaling Governors调频策略CPUFreq提供可与所有 scaling driver 搭配使用的通用 scaling governors。每个 governor 实现一个可能参数化的性能缩放算法。要点governor 附着到 policy 对象不同 policy 对象可以同时由不同 governor 处理尽管在某些情况下可能导致次优结果给定 policy 的 governor 可随时通过 sysfs 的scaling_governor属性更改部分 governor 通过 sysfs 暴露用于控制/微调控频算法的属性即governor tunables。它们可以是全局系统范围或每-policy的取决于所用的 scaling driver若 driver 要求 tunables 按 policy 隔离它们位于每个 policy 目录的子目录中否则位于/sys/devices/system/cpu/cpufreq/下的子目录中。无论哪种情况存放 governor tunables 的子目录名都是提供它们的 governor 名称。6.1performance附着到 policy 对象时该 governor 会为该 policy 请求最高频率在scaling_max_freqpolicy 限制范围内。请求发生在 governor 被设置为performance的时刻以及此后scaling_max_freq或scaling_min_freqpolicy 限制发生变化时。对应实现见 drivers/cpufreq/cpufreq_performance.c。6.2powersave附着到 policy 对象时该 governor 会为该 policy 请求最低频率在scaling_min_freqpolicy 限制范围内。请求发生在 governor 被设置为powersave的时刻以及此后 policy 限制变化时。对应实现见 drivers/cpufreq/cpufreq_powersave.c。6.3userspace该 governor 自身不主动做任何事而是允许用户空间通过写入该 policy 的scaling_setspeed属性来设置 CPU 频率。需要注意的是即使意图是设置一个精确频率实际频率仍可能因硬件协调hardware coordination、热与功耗限制等因素而有所偏差。对应实现见 drivers/cpufreq/cpufreq_userspace.c。6.4schedutil该 governor 使用 CPU 调度器提供的利用率数据通常被视为 CPU 调度器的一部分因此可以直接访问调度器的内部数据结构。它完全运行在调度器上下文中但在某些情况下当它决定某 policy 应改变 CPU 频率时可能需要异步调用 scaling driver这取决于 driver 是否能够在调度器上下文中改变频率。该 governor 对某 CPU 的具体行为取决于调用其利用率更新回调的调度类若由RT 或 deadline 调度类调用governor 会将频率提升到允许的最大值即scaling_max_freqpolicy 限制若由CFS 调度类调用governor 使用给定 CPU 根控制组的Per-Entity Load TrackingPELT指标作为 CPU 利用率估计然后按如下公式计算要应用的频率f 1.25 * f_0 * util / max其中util是 PELT 数值max是util的理论最大值f_0是给定 policy 的最大可能 CPU 频率若 PELT 数值是频率不变/frequency-invariant 的否则为当前 CPU 频率。从源码看kernel/sched/cpufreq_schedutil.c 中明确注释了取 C 1.25 的动机使频率翻转点tipping point位于util / max 0.8处同时最终选择的频率会取驱动支持的不低于原始 next_freq 的最低频率并受 policy 的 min/max 与 cpufreq driver 限制约束。该 governor 还实现了IO-wait boosting机制当调度器向 governor 回调传入SCHED_CPUFREQ_IOWAIT标志时频率会立即提升到允许的最大值随后随时间回落至上述公式计算出的值。源码中 kernel/sched/cpufreq_schedutil.c 展示了其实现细节每次任务从 IO 等待中唤醒时CPU 利用率可被提升到某个值该值在频繁且连续的 IO 唤醒中每次翻倍范围从IOWAIT_BOOST_MINSCHED_CAPACITY_SCALE / 8到最大 OPP 的利用率若一个 tick 内未再次请求 IO boost则从最小 OPP 的利用率重新开始从而避免忽略偶发的 IO 唤醒带来的能源浪费。schedutil只暴露一个 tunablerate_limit_us两次连续 governor 计算之间必须经过的最短时间微秒。默认值为 scaling driver 转换延迟transition latency的1.5 倍若 driver 未提供延迟值则为1ms。该 tunable 的目的是降低 governor 在调度器上下文的开销没有它可能过大。源码中 kernel/sched/cpufreq_schedutil.c 通过cpufreq_policy_transition_delay_us(policy)计算默认值。该 governor 一般被视为较老的ondemand与conservativegovernor见下文的替代品它更简单、与 CPU 调度器集成更紧密、在 CPU 上下文切换等方面的开销更小并且使用调度器自身的 CPU 利用率指标因此原则上其决策不应与调度器其他部分的决策相矛盾。6.5ondemand该 governor 使用CPU 负载作为频率选择指标。为估算当前 CPU 负载它测量其 worker 例程两次连续调用之间的时间间隔并计算该时间段内给定 CPU 非空闲active时间的占比——非空闲时间与总 CPU 时间的比值即负载估计。若该 governor 附着到多 CPU 共享的 policy则为所有 CPU 估计负载并取最大值作为整个 policy 的负载估计。该 governor 的 worker 例程必须在进程上下文运行因此通过工作队列异步调用必要时从那里更新 CPU P-state。结果是该 governor 在调度器上下文的开销最小但会造成相对频繁的额外 CPU 上下文切换且其触发的 P-state 更新可能相对不规则同时它运行的代码会减少 CPU 空闲时间从而轻微影响它自身的负载指标。它通常选择与估计负载成比例的 CPU 频率cpuinfo_max_freq对应负载 1100%cpuinfo_min_freq对应负载 0但当负载超过可配置的加速阈值speedup threshold时它会直接跳到允许的最高频率scaling_max_freqpolicy 限制。该 governor 暴露以下 tunables对应实现见 drivers/cpufreq/cpufreq_ondemand.csampling_rategovernor 的 worker 例程应运行的频率微秒。通常设为 20002ms量级。默认值为在每个附着该 governor 的 policy 上给cpuinfo_transition_latency加上 50% 的余量breathing room最小值通常是两个调度器 tick 的长度。若该 tunable 是每-policy 的以下命令可将其设为转换延迟的 1.5 倍即默认值# echo $(($(cat cpuinfo_transition_latency) * 3 / 2)) ondemand/sampling_rateup_threshold若估计 CPU 负载高于此值百分比governor 将频率设置为该 policy 允许的最大值否则所选频率与估计负载成比例。ignore_nice_load若设为 1默认 0CPU 负载估算代码会将执行 nice 级别大于 0 的任务所花费的 CPU 时间视为 CPU 空闲时间。当系统中存在不应参与频率决策的任务时很有用只需将这些任务的 nice 级别提高到 0 以上并将此属性设为 1。sampling_down_factor1默认到 100000含之间的临时乘数应用于sampling_rate值——当 CPU 负载超过up_threshold时生效。它会使 governor worker 例程的下一次执行在将频率设为允许最大值之后被延迟从而让频率在最大值维持更长时间。可避免某些突发工作负载下的频率波动代价是在维持最大 CPU 容量上消耗额外能量。powersave_bias应用于 governor 原始频率目标包括负载超过up_threshold时使用的最大值的削减因子或用于 AMD 频率敏感度省电偏置驱动drivers/cpufreq/amd_freq_sensitivity.c的敏感度阈值取值范围 0 到 1000含。若该驱动未加载实际应用频率为f * (1 - powersave_bias / 1000)其中 f 是 governor 的原始频率目标此时该属性默认值为 0。若 AMD 频率敏感度省电偏置驱动已加载该属性默认值为 400且以不同方式使用在 Family 16h及更新AMD 处理器上可从硬件获取 0 到 100% 的实测工作负载敏感度用于估计工作负载性能随频率变化的响应。敏感度为 0 的工作负载内存或 IO 密集型预期不会因提高频率而获得性能提升而敏感度 100% 的工作负载CPU 密集型预期在提高频率后表现更好。若工作负载敏感度低于powersave_bias代表的阈值该驱动会使 governor 选择低于其原始目标的频率从而避免为不会从更高频率获益的工作负载过度配置over-provisioning。6.6conservative该 governor 也使用CPU 负载作为频率选择指标负载估算方式与ondemand相同但频率选择算法不同。它避免在短时间内显著改变频率这对于供电容量有限的系统例如电池供电设备可能更合适。为此它以相对较小的步长逐步调整频率——每次向上或向下改变一个步长具体方向取决于估计 CPU 负载是否超过可配置的阈值。该 governor 暴露以下 tunables对应实现见 drivers/cpufreq/cpufreq_conservative.cfreq_step频率步长以 governor 被允许设置的最高频率scaling_max_freqpolicy 限制的百分比表示取值 0 到 100默认 5。这是频率一次允许改变的量。设为 0 完全禁用 governor 的频率更改设为 100 则实际上使 governor 在scaling_min_freq与scaling_max_freqpolicy 限制之间周期性地切换频率。源码中 drivers/cpufreq/cpufreq_conservative.c 的计算为freq_step (cs_tuners-freq_step * policy-max) / 100。down_threshold用于确定频率变化方向的阈值百分比默认 20。若估计 CPU 负载大于此值频率上升增加freq_step若负载小于此值且sampling_down_factor机制未生效频率下降否则频率不变。sampling_down_factor频率下降延迟因子1默认到 10含。它实际上使频率下降速度比上升速度慢sampling_down_factor倍。七、频率 BoostFrequency Boost支持7.1 背景某些处理器支持在特定条件下临时将多核封装中部分核心的运行频率提高到整个封装的可持续频率阈值之上例如当整个芯片未被完全利用且低于其预期热/功耗预算时。不同厂商对此功能有不同的称呼Intel 称为Turbo BoostAMD 称为Turbo-Core技术文档中为Core Performance Boost等。不同厂商的实现方式也各异。本文统一用术语frequency boost频率提升指代所有这些实现。频率提升机制可能基于硬件或软件硬件驱动如 x86是否触发提升由硬件决定通常要求硬件被置入一个特殊状态在该状态下它能在一组限制内控制 CPU 频率软件驱动如 ARM由 scaling driver 决定是否及何时触发提升。7.2 sysfs 中的boost文件该文件位于/sys/devices/system/cpu/cpufreq/下控制全系统的 boost 设置。若底层 scaling driver 不支持频率提升机制或支持但提供 driver 专有接口控制它如 intel_pstate则该文件不存在。语义如下值为1频率提升机制被启用——要么硬件可以被置入能触发提升的状态硬件驱动情形要么软件被允许触发提升软件驱动情形。注意这并不表示此刻系统中有任何 CPU 实际在使用提升它只代表使用频率提升机制的许可可能因其他原因永远不会被使用值为0频率提升机制被禁用完全不能使用。可以写入该文件的只有0 和 1两个值。7.3 提供 Boost 控制旋钮的理由频率提升机制总体上有助于在软件分辨率以下的时间尺度例如调度器 tick 间隔以下获得最佳 CPU 性能对许多工作负载都适用但在某些情况下也可能带来问题。因此许多系统允许在平台固件BIOS设置中禁用频率提升但这需要重启系统才能生效至少在某些场景下不切实际。可运行的boost控制旋钮则解决了这一问题例如省电提升意味着在受控条件下对处理器超频。通常提高频率与电压会增加处理器能耗即使是暂时的。对于切换到有限容量电源如电池的系统这可能不合需要因此在系统运行期间禁用提升机制可能会有所帮助不过也取决于工作负载确定性行为某些情况下确定性比性能或能耗或两者更重要运行时禁用提升能力可能很有用评估提升机制本身的影响能够在不重启系统的前提下分别运行开启/关闭提升的测试是非常有用的基准测试可复现性运行基准测试时可复现的结果很重要。由于提升功能取决于整个封装package的负载单线程性能可能因此波动有时会导致结果不可复现。在运行对该问题敏感的基准测试前禁用频率提升机制可以避免这种情况。7.4 遗留的 AMDcpb旋钮AMD 的 powernow-k8 scaling driver 支持一个与全局boost非常相似的 sysfs 旋钮用于禁用/启用某些 AMD 处理器的 Core Performance Boost 特性若存在该旋钮位于每个CPUFreqpolicy 目录中/sys/devices/system/cpu/cpufreq/policyX/名为cpb表示更细粒度的控制接口然而实际实现是系统范围的——为一个 policy 设置该旋钮会同时为所有其他 policy 设置相同值该旋钮在支持其底层硬件特性的 AMD 处理器上仍受支持但可以通过CONFIG_X86_ACPI_CPUFREQ_CPB配置选项将其从内核中配置掉而全局boost旋钮始终存在因此始终可以用boost旋钮替代cpb这被强烈推荐因为它与所有其他系统的做法更一致而且cpb旋钮未来可能不再受支持对于没有底层硬件特性的处理器如所有 Intel 处理器即使设置了CONFIG_X86_ACPI_CPUFREQ_CPB配置选项cpb旋钮也永远不会出现。八、动手实践查看与调整当前系统的 CPU 调频基于上述原理以下命令可帮助你快速查看并管理当前系统的 CPU 性能缩放示例输出因平台而异# 查看当前使用的 scaling driver 与可用 governor cat /sys/devices/system/cpu/cpufreq/policy0/scaling_driver cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors # 查看当前 governor、频率上下限与硬件能力 cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq # 切换 governor如切换到 userspace 手动控频 echo userspace | sudo tee /sys/devices/system/cpu/cpufreq/policy0/scaling_governor # 设置频率上下限不得交叉 echo 2000000 | sudo tee /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq echo 800000 | sudo tee /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq # 在 userspace governor 下手动指定频率 echo 1800000 | sudo tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed # 查看/切换全系统频率提升需驱动支持 cat /sys/devices/system/cpu/cpufreq/boost echo 0 | sudo tee /sys/devices/system/cpu/cpufreq/boost # 禁用 boost echo 1 | sudo tee /sys/devices/system/cpu/cpufreq/boost # 启用 boost # 查看 governor tunables全局模式位于 cpufreq 目录下每-policy 模式位于 policyX 子目录 ls /sys/devices/system/cpu/cpufreq/ondemand/ cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold需要说明的适用前提以上路径与属性是否全部存在取决于当前内核配置、所加载的 scaling driver例如 intel_pstate 驱动会改变scaling_available_governors的语义并自带boost控制方式以及底层硬件特性。若某项属性不存在通常意味着对应驱动或硬件不支持该特性而非系统异常。九、延伸阅读Documentation/admin-guide/pm/intel_pstate.rstintel_pstate scaling driver 的详细说明绕过 governor 层的典型实现Documentation/admin-guide/pm/cpufreq_drivers.rst各平台 scaling driver 的说明核心实现drivers/cpufreq/cpufreq.cCPUFreq core 与 sysfs 接口、include/linux/cpufreq.hstruct cpufreq_policy 等数据结构定义governor 实现drivers/cpufreq/cpufreq_ondemand.c、drivers/cpufreq/cpufreq_conservative.c、kernel/sched/cpufreq_schedutil.c代表性 scaling driverdrivers/cpufreq/intel_pstate.cx86 Intel、drivers/cpufreq/amd-pstate.cx86 AMD、drivers/cpufreq/acpi-cpufreq.cACPI、drivers/cpufreq/cpufreq-dt.cDevice Tree 平台、drivers/cpufreq/qcom-cpufreq-hw.cQualcomm完整驱动清单见 drivers/cpufreq/ 目录。【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考