CPU 性能调节¶

版权:: © 2017 英特尔公司
作者:: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

CPU 性能调节的概念¶

大多数现代处理器都能够在多种不同的时钟频率和电压配置下运行，通常称为工作性能点或 P 状态（在 ACPI 术语中）。通常，时钟频率越高，电压越高，CPU 在单位时间内可以执行的指令就越多，但时钟频率越高，电压越高，CPU 在给定 P 状态下单位时间内消耗的能量（或消耗的功率）也就越多。因此，CPU 容量（单位时间内可以执行的指令数）和 CPU 消耗的功率之间存在天然的权衡。

在某些情况下，希望甚至有必要尽可能快地运行程序，那么就没有理由使用任何与最高 P 状态（即可用的最高性能频率/电压配置）不同的 P 状态。但是，在某些其他情况下，可能没有必要如此快速地执行指令，并且在相对较长的时间内保持可用的最高 CPU 容量而不完全利用它可能被认为是浪费的。由于散热或电源容量原因或类似原因，也可能无法在太长时间内保持最大 CPU 容量。为了涵盖这些情况，存在允许 CPU 在不同频率/电压配置之间切换或（在 ACPI 术语中）进入不同 P 状态的硬件接口。

通常，它们与估计所需 CPU 容量的算法一起使用，以便决定将 CPU 置于哪些 P 状态。当然，由于系统的利用率通常会随着时间的推移而变化，因此必须定期重复执行此操作。发生这种情况的活动称为 CPU 性能调节或 CPU 频率调节（因为它涉及调整 CPU 时钟频率）。

Linux 中的 CPU 性能调节¶

Linux 内核通过 CPUFreq (CPU 频率调节) 子系统来支持 CPU 性能调节，该子系统由三层代码组成：核心、调节器和驱动程序。

CPUFreq 核心为所有支持 CPU 性能调节的平台提供公共代码基础结构和用户空间接口。它定义了其他组件运行的基本框架。

调节器实现算法以估计所需的 CPU 容量。通常，每个调节器都实现一个，可能是参数化的调节算法。

驱动程序与硬件通信。它们为调节器提供有关可用 P 状态（或在某些情况下为 P 状态范围）的信息，并访问平台特定的硬件接口以按照调节器的请求更改 CPU P 状态。

原则上，所有可用的调节器都可以与每个驱动程序一起使用。该设计基于以下观察结果：在大多数情况下，性能调节算法用于 P 状态选择的信息可以用平台无关的形式表示，因此应该可以使用以完全相同的方式实现的相同性能调节算法，而与使用哪个驱动程序无关。因此，同一组调节器应适用于每个受支持的平台。

但是，对于基于硬件本身提供的信息（例如通过反馈寄存器）的性能调节算法，该观察结果可能不成立，因为该信息通常特定于其来自的硬件接口，并且可能不容易以抽象的、平台无关的方式表示。因此，CPUFreq 允许驱动程序绕过调节器层并实现自己的性能调节算法。这是由 intel_pstate 驱动程序完成的。

`CPUFreq` 策略对象¶

在某些情况下，用于 P 状态控制的硬件接口由多个 CPU 共享。例如，使用相同的寄存器（或寄存器集）同时控制多个 CPU 的 P 状态，并且写入它会同时影响所有这些 CPU。

共享硬件 P 状态控制接口的 CPU 集由 CPUFreq 表示为 struct cpufreq_policy 对象。为了保持一致性，当给定集中只有一个 CPU 时，也使用 struct cpufreq_policy。

CPUFreq 核心为系统中的每个 CPU（包括当前离线的 CPU）维护指向 struct cpufreq_policy 对象的指针。如果多个 CPU 共享相同的硬件 P 状态控制接口，则与它们对应的所有指针都指向相同的 struct cpufreq_policy 对象。

CPUFreq 使用 struct cpufreq_policy 作为其基本数据类型，并且其用户空间接口的设计基于策略概念。

CPU 初始化¶

首先，必须注册驱动程序才能使 CPUFreq 工作。一次只能注册一个驱动程序，因此驱动程序应能够处理系统中的所有 CPU。

可以在 CPU 注册之前或之后注册驱动程序。如果 CPU 较早注册，则驱动程序核心会调用 CPUFreq 核心，以在注册驱动程序期间记录所有已注册的 CPU。反过来，如果在注册驱动程序后注册任何 CPU，则会调用 CPUFreq 核心，以在注册时记录它们。

在任何情况下，只要准备好处理该 CPU，就会调用 CPUFreq 核心以记录到目前为止尚未见过的任何逻辑 CPU。[请注意，逻辑 CPU 可能是物理单核处理器，或者多核处理器中的单个内核，或者是物理处理器或处理器内核中的硬件线程。在下文中，“CPU”始终表示“逻辑 CPU”，除非明确说明，否则使用单词“处理器”来指代可能包括多个逻辑 CPU 的物理部分。]

一旦调用，CPUFreq 核心会检查是否已为给定的 CPU 设置策略指针，如果是，则跳过策略对象创建。否则，将创建并初始化一个新的策略对象，其中包括在 sysfs 中创建一个新的策略目录，并将与给定 CPU 对应的策略指针设置为内存中新策略对象的地址。

接下来，将调用缩放驱动程序的 ->init() 回调函数，并将新 CPU 的策略指针作为参数传递给它。该回调函数应初始化给定 CPU 的性能缩放硬件接口（或者更准确地说，初始化属于同一硬件接口的一组 CPU，由其策略对象表示），并且如果被调用的策略对象是新的，则应设置策略的参数，例如硬件支持的最小和最大频率、可用频率表（如果支持的 P 状态不是连续范围），以及属于同一策略的 CPU 的掩码（包括在线和离线 CPU）。然后，核心将使用该掩码为其中的所有 CPU 填充策略指针。

新策略对象的下一个主要初始化步骤是将缩放调速器附加到它（首先，这是由内核命令行或配置确定的默认缩放调速器，但稍后可以通过 sysfs 进行更改）。首先，新策略对象的指针会传递给调速器的 ->init() 回调函数，该函数应初始化处理给定策略所需的所有数据结构，并且可能会向其添加一个调速器 sysfs 接口。接下来，通过调用其 ->start() 回调函数来启动调速器。

该回调函数应向 CPU 调度器注册属于给定策略的所有在线 CPU 的每个 CPU 利用率更新回调。CPU 调度器会在重要事件（如任务入队和出队）、调度器时钟的每次迭代或通常在 CPU 利用率可能发生变化时（从调度器的角度来看）调用利用率更新回调。它们应执行确定给定策略的后续 P 状态所需的计算，并调用缩放驱动程序以根据 P 状态选择对硬件进行更改。缩放驱动程序可以直接从调度器上下文调用，也可以根据缩放驱动程序和调速器的配置和功能，通过内核线程或工作队列异步调用。

对于不是新的，而是先前“不活动”的策略对象，也会采取类似的步骤，这意味着属于它们的所有 CPU 都处于离线状态。在这种情况下，唯一的实际区别是 CPUFreq 核心将尝试使用先前与变为“不活动”（现在重新初始化）的策略一起使用的缩放调速器，而不是默认的调速器。

反过来，如果先前离线的 CPU 正在恢复在线状态，但与之共享策略对象的其他一些 CPU 已经在线，则完全不需要重新初始化策略对象。在这种情况下，只需要重新启动缩放调速器，以便它可以将新的在线 CPU 考虑在内。这是通过按顺序调用整个策略的调速器的 ->stop 和 ->start() 回调函数来实现的。

如前所述，intel_pstate 缩放驱动程序绕过了 CPUFreq 的缩放调速器层，并提供其自己的 P 状态选择算法。因此，如果使用 intel_pstate，则不会将缩放调速器附加到新的策略对象。相反，会调用驱动程序的 ->setpolicy() 回调函数，为每个策略注册每个 CPU 的利用率更新回调。CPU 调度器以与缩放调速器相同的方式调用这些回调，但在 intel_pstate 情况下，它们都会确定要使用的 P 状态，并从调度器上下文中一次性更改硬件配置。

在取消注册缩放驱动程序时（例如，当卸载包含它的内核模块时）或当取消注册属于给定策略的最后一个 CPU 时，会拆除在 CPU 初始化期间创建的策略对象以及与之关联的其他数据结构。

`sysfs` 中的策略接口¶

在内核初始化期间，CPUFreq 核心会在 /sys/devices/system/cpu/ 下创建一个名为 cpufreq 的 sysfs 目录（kobject）。

该目录包含每个由 CPUFreq 核心维护的策略对象的 policyX 子目录（其中 X 表示一个整数）。每个 policyX 目录都由 /sys/devices/system/cpu/cpuY/ 下的 cpufreq 符号链接指向（其中 Y 表示一个可能与 X 表示的整数不同的整数），适用于与给定策略关联（或属于该策略）的所有 CPU。/sys/devices/system/cpu/cpufreq 中的 policyX 目录各自包含特定于策略的属性（文件），以控制相应策略对象（即，与它们关联的所有 CPU）的 CPUFreq 行为。

其中一些属性是通用的。它们由 CPUFreq 核心创建，其行为通常不取决于正在使用的缩放驱动程序以及附加到给定策略的缩放调速器。一些缩放驱动程序还会向 sysfs 中的策略目录添加特定于驱动程序的属性，以控制驱动程序行为的特定于策略的方面。

/sys/devices/system/cpu/cpufreq/policyX/ 下的通用属性如下：

affected_cpus

属于此策略的在线 CPU 列表（即，共享由 policyX 策略对象表示的硬件性能缩放接口）。

bios_limit

如果平台固件 (BIOS) 告知操作系统对 CPU 频率应用上限，则该上限将通过此属性报告（如果存在）。

限制的存在可能是某些（通常是无意的）BIOS 设置、来自服务处理器或其他基于 BIOS/HW 的机制的限制的结果。

这不包括可以通过通用散热驱动程序发现的 ACPI 散热限制。

如果正在使用的缩放驱动程序不支持此属性，则此属性不存在。

cpuinfo_cur_freq

从此硬件获得的属于此策略的 CPU 的当前频率（以 KHz 为单位）。

预计这是硬件实际运行的频率。如果无法确定该频率，则不应存在此属性。

cpuinfo_max_freq

属于此策略的 CPU 可以运行的最大可能工作频率（以 kHz 为单位）。

cpuinfo_min_freq

属于此策略的 CPU 可以运行的最小可能工作频率（以 kHz 为单位）。

cpuinfo_transition_latency

将属于此策略的 CPU 从一个 P 状态切换到另一个 P 状态所需的时间，以纳秒为单位。

如果未知，或者已知非常高以至于缩放驱动程序不使用 ondemand 调速器，则从此属性的读取将返回 -1 (CPUFREQ_ETERNAL)。

related_cpus

属于此策略的所有（在线和离线）CPU 的列表。

scaling_available_frequencies

属于此策略的 CPU 的可用频率列表（以 kHz 为单位）。

scaling_available_governors

内核中存在的可以附加到此策略的 CPUFreq 缩放调速器的列表，或者（如果正在使用 intel_pstate 缩放驱动程序）可以应用于此策略的驱动程序提供的缩放算法的列表。

（请注意，某些调速器是模块化的，可能需要加载内核模块才能使其持有的调速器可用并由此属性列出。）

scaling_cur_freq

属于此策略的所有 CPU 的当前频率（以 kHz 为单位）。

在大多数情况下，这是缩放驱动程序使用其提供的缩放接口从硬件请求的最后一个 P 状态的频率，这可能反映也可能不反映 CPU 实际运行的频率（由于硬件设计和其他限制）。

某些架构（例如 x86）可能会尝试通过此属性提供更准确地反映当前 CPU 频率的信息，但这仍然可能不是硬件此刻看到的准确的当前 CPU 频率。

scaling_driver

当前正在使用的缩放驱动程序。

scaling_governor

当前附加到此策略的缩放调速器，或者（如果正在使用 intel_pstate 缩放驱动程序）当前应用于此策略的驱动程序提供的缩放算法。

此属性是可读写的，对其进行写入将导致新的缩放调速器附加到此策略，或者应用缩放驱动程序提供的新缩放算法（在 intel_pstate 情况下），如写入此属性的字符串所示（该字符串必须是上面描述的 scaling_available_governors 属性列出的名称之一）。

scaling_max_freq

允许属于此策略的 CPU 运行的最大频率（以 kHz 为单位）。

此属性是可读写的，写入表示整数的字符串将导致设置新的限制（它不得低于 scaling_min_freq 属性的值）。

scaling_min_freq

允许属于此策略的 CPU 运行的最小频率（以 kHz 为单位）。

此属性是可读写的，写入表示非负整数的字符串将导致设置新的限制（它不得高于 scaling_max_freq 属性的值）。

scaling_setspeed

仅当 userspace 缩放调速器附加到给定策略时，此属性才起作用。

它返回调速器请求的最后一个频率（以 kHz 为单位），或者可以写入以设置策略的新频率。

通用缩放调速器¶

CPUFreq 提供可用于所有缩放驱动程序的通用缩放调速器。如前所述，它们中的每一个都实现一个单独的（可能参数化的）性能缩放算法。

缩放调速器附加到策略对象，并且不同的策略对象可以同时由不同的缩放调速器处理（尽管在某些情况下可能会导致次优结果）。

可以使用 sysfs 中的 scaling_governor 策略属性随时更改给定策略对象的缩放调速器。

一些调速器会暴露 sysfs 属性，以控制或微调它们实现的频率调节算法。这些属性被称为调速器可调参数，可以是全局的（系统范围的）或每个策略的，具体取决于所使用的频率调节驱动程序。如果驱动程序要求调速器可调参数是每个策略的，则它们位于每个策略目录的子目录中。否则，它们位于 /sys/devices/system/cpu/cpufreq/ 下的子目录中。在任何一种情况下，包含调速器可调参数的子目录的名称都是提供这些参数的调速器的名称。

`performance`¶

当附加到策略对象时，此调速器会请求该策略在 scaling_max_freq 策略限制内的最高频率。

该请求在策略的调速器设置为 performance 时以及 scaling_max_freq 或 scaling_min_freq 策略限制更改后，都会执行一次。

`powersave`¶

当附加到策略对象时，此调速器会请求该策略在 scaling_min_freq 策略限制内的最低频率。

该请求在策略的调速器设置为 powersave 时以及 scaling_max_freq 或 scaling_min_freq 策略限制更改后，都会执行一次。

`userspace`¶

此调速器本身不执行任何操作。相反，它允许用户空间通过写入该策略的 scaling_setspeed 属性来设置其所附加策略的 CPU 频率。

`schedutil`¶

此调速器使用 CPU 调度程序提供的 CPU 利用率数据。它通常被认为是 CPU 调度程序的一部分，因此它可以直接访问调度程序的内部数据结构。

它完全在调度程序上下文中运行，尽管在某些情况下，当它决定应该为给定策略更改 CPU 频率时，它可能需要异步调用频率调节驱动程序（这取决于驱动程序是否能够从调度程序上下文中更改 CPU 频率）。

此调速器针对特定 CPU 的行为取决于为该 CPU 调用其利用率更新回调的调度类。如果它由 RT 或 deadline 调度类调用，则调速器会将频率提高到允许的最大值（即 scaling_max_freq 策略限制）。反过来，如果它由 CFS 调度类调用，则调速器将使用给定 CPU 的根控制组的 Per-Entity Load Tracking (PELT) 指标作为 CPU 利用率估计值（有关 PELT 机制的描述，请参阅 LWN.net 文章 Per-entity load tracking [1]）。然后，根据以下公式计算要应用的新 CPU 频率

f = 1.25 * f_0 * util / max

其中 util 是 PELT 数，max 是 util 的理论最大值，f_0 是给定策略的最大可能 CPU 频率（如果 PELT 数与频率无关），否则是当前 CPU 频率。

此调速器还采用了一种机制，允许它临时提高最近等待 I/O 的任务的 CPU 频率，称为“IO-wait boosting”。当调度程序将 SCHED_CPUFREQ_IOWAIT 标志传递给调速器回调时会发生这种情况，这会导致频率立即上升到允许的最大值，然后随着时间的推移回落到上述公式返回的值。

此调速器仅公开一个可调参数

rate_limit_us

调速器计算的两次连续运行之间必须经过的最小时间（以微秒为单位）（默认值：频率调节驱动程序转换延迟的 1.5 倍或最大 2 毫秒）。

此可调参数的目的是减少调速器的调度程序上下文开销，如果没有它，开销可能会过大。

此调速器通常被认为是较旧的 ondemand 和 conservative 调速器（如下所述）的替代品，因为它更简单，并且与 CPU 调度程序集成得更紧密，它在 CPU 上下文切换等方面的开销较小，并且它使用调度程序自身的 CPU 利用率指标，因此原则上其决策不应与调度程序的其他部分所做的决策相矛盾。

`ondemand`¶

此调速器使用 CPU 负载作为 CPU 频率选择指标。

为了估计当前的 CPU 负载，它会测量其工作程序例程的连续调用之间经过的时间，并计算给定 CPU 不处于空闲状态的时间比例。非空闲（活动）时间与 CPU 总时间的比率被用作负载的估计值。

如果此调速器附加到多个 CPU 共享的策略，则会估计所有 CPU 的负载，并将最大的结果作为整个策略的负载估计值。

此调速器的工作程序例程必须在进程上下文中运行，因此它是异步调用的（通过工作队列），并且 CPU P 状态会在必要时从那里更新。因此，此调速器的调度程序上下文开销最小，但它会导致相对频繁地发生额外的 CPU 上下文切换，并且由它触发的 CPU P 状态更新可能相对不规则。此外，它通过运行代码来减少 CPU 空闲时间来影响其自身的 CPU 负载指标（尽管 CPU 空闲时间仅会因此而略微减少）。

它通常选择与估计负载成比例的 CPU 频率，因此 cpuinfo_max_freq 策略属性的值对应于负载 1（或 100%），而 cpuinfo_min_freq 策略属性的值对应于负载 0，除非负载超过（可配置的）加速阈值，在这种情况下，它会直接使用允许使用的最高频率（scaling_max_freq 策略限制）。

此调速器公开以下可调参数

sampling_rate

这是调速器的工作程序例程应运行的频率，以微秒为单位。

通常，它设置为 2000（2 毫秒）左右的值。它的默认值是在此调速器所附加的每个策略上，为 cpuinfo_transition_latency 增加 50% 的缓冲空间。最小值通常是两个调度程序滴答的长度。

如果此可调参数是每个策略的，则以下 shell 命令会将它表示的时间设置为转换延迟的 1.5 倍（默认值）

# echo `$(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate

up_threshold

如果估计的 CPU 负载高于此值（以百分比表示），则调速器会将频率设置为该策略允许的最大值。否则，所选频率将与估计的 CPU 负载成比例。

ignore_nice_load

如果设置为 1（默认值为 0），它将使 CPU 负载估计代码将花费在执行“nice”级别大于 0 的任务上的 CPU 时间视为 CPU 空闲时间。

如果系统中有一些任务不应在决定以什么频率运行 CPU 时考虑在内，这可能会很有用。然后，要实现这一点，只需将这些任务的“nice”级别提高到 0 以上，并将此属性设置为 1。

sampling_down_factor

临时乘数，介于 1（默认值）和 100 之间（包括 1 和 100），用于在 CPU 负载高于 up_threshold 时应用于 sampling_rate 值。

这会导致调速器的工作程序例程的下一次执行（在将频率设置为允许的最大值之后）被延迟，因此频率会在最大级别保持更长时间。

在一些突发工作负载中，可以以维持最大 CPU 容量所花费的额外能量为代价，避免频率波动。

powersave_bias

用于应用于调速器的原始频率目标（包括当估计的 CPU 负载超过 up_threshold 值时使用的最大值）的缩减系数，或 AMD 频率敏感度节能偏置驱动程序 (drivers/cpufreq/amd_freq_sensitivity.c) 的灵敏度阈值，介于 0 和 1000 之间（包括 0 和 1000）。

如果未加载 AMD 频率敏感度节能偏置驱动程序，则要应用的有效频率由下式给出

f * (1 - powersave_bias / 1000)

其中 f 是调速器的原始频率目标。在这种情况下，此属性的默认值为 0。

如果加载了 AMD 频率敏感度节能偏置驱动程序，则此属性的默认值为 400，并且以不同的方式使用。

在 Family 16h（及更高版本）的 AMD 处理器上，有一种机制可以从硬件获取测得的工作负载敏感度，介于 0 和 100% 之间（包括 0 和 100%）。该值可用于估计在 CPU 频率发生变化时，CPU 上运行的工作负载的性能会发生怎样的变化。

如果 CPU 频率增加，则敏感度为 0 的工作负载（内存受限或 IO 受限）的性能预计不会有任何提高，而敏感度为 100% 的工作负载（CPU 受限）如果 CPU 频率增加，则预计性能会好得多。

如果工作负载敏感度小于 powersave_bias 值表示的阈值，则敏感度节能偏置驱动程序将导致调速器选择低于其原始目标的频率，从而避免过度配置在更高 CPU 频率下运行不会受益的工作负载。

`conservative`¶

此调速器使用 CPU 负载作为 CPU 频率选择指标。

它以与上面描述的 ondemand 调速器相同的方式估计 CPU 负载，但它实现的 CPU 频率选择算法不同。

也就是说，它避免在短时间内显著改变频率，这可能不适合电源容量有限的系统（例如，电池供电的系统）。为了实现这一点，它以相对小的步长，一次一步地向上或向下改变频率 - 这取决于估计的 CPU 负载是否超过了（可配置的）阈值。

此调速器公开以下可调参数

freq_step

频率步长，以调速器允许设置的最大频率（scaling_max_freq 策略限制）的百分比表示，介于 0 和 100 之间（默认为 5）。

这是允许一次更改的频率量。将其设置为 0 将导致使用默认频率步长（5%），将其设置为 100 实际上会导致调速器周期性地在 scaling_min_freq 和 scaling_max_freq 策略限制之间切换频率。

down_threshold

用于确定频率变化方向的阈值（以百分比表示，默认为 20）。

如果估计的 CPU 负载大于此值，则频率将上升（按 freq_step）。如果负载小于此值（并且 sampling_down_factor 机制不起作用），则频率将下降。否则，频率将不会改变。

sampling_down_factor

频率降低延迟因子，介于 1（默认）和 10（包括）之间。

它实际上使频率下降的速度比上升的速度慢 sampling_down_factor 倍。

频率加速支持¶

背景¶

一些处理器支持一种机制，在某些条件下（例如，如果整个芯片没有被充分利用并且低于其预期的热或功率预算），可以临时提高多核封装中某些内核的工作频率（并且高于整个封装的可持续频率阈值）。

不同的供应商使用不同的名称来指代此功能。对于 Intel 处理器，它被称为“Turbo Boost”，AMD 称之为“Turbo-Core”或（在技术文档中）“Core Performance Boost”等等。通常，不同的供应商也以不同的方式实现它。这里为了简洁起见，使用简单术语“频率加速”来指代所有这些实现。

频率加速机制可以是基于硬件的，也可以是基于软件的。如果它是基于硬件的（例如，在 x86 上），则触发加速的决定由硬件做出（尽管通常需要将硬件置于一种特殊状态，在该状态下，它可以控制一定范围内的 CPU 频率）。如果它是基于软件的（例如，在 ARM 上），则缩放驱动程序决定是否触发加速以及何时触发加速。

`sysfs` 中的 `boost` 文件¶

此文件位于 /sys/devices/system/cpu/cpufreq/ 下，并控制整个系统的“加速”设置。如果底层缩放驱动程序不支持频率加速机制（或支持它，但为控制它提供了一个驱动程序特定的接口，如 intel_pstate），则该文件不存在。

如果此文件中的值为 1，则启用频率加速机制。这意味着硬件可以被置于可以触发加速的状态（在基于硬件的情况下），或者允许软件触发加速（在基于软件的情况下）。这并不意味着系统中的任何 CPU 当前都在实际使用加速。它仅表示允许使用频率加速机制（出于其他原因，可能永远不会使用）。

如果此文件中的值为 0，则禁用频率加速机制，并且根本无法使用。

可以写入此文件的唯一值是 0 和 1。

加速控制旋钮的原理¶

频率加速机制通常旨在帮助在低于软件分辨率的时间尺度（例如，低于调度程序滴答间隔）上实现最佳 CPU 性能，并且对于许多工作负载来说，它显然是合适的，但在某些情况下，它可能会导致问题。

因此，许多系统允许在平台固件 (BIOS) 设置中禁用频率加速机制，但这需要重新启动系统才能根据需要调整设置，这至少在某些情况下可能不切实际。例如

加速意味着超频处理器，尽管是在受控条件下。通常，处理器能耗会随着频率和电压的升高而增加，即使是暂时的。这在切换到容量有限的电源（如电池）的系统上可能是不希望的，因此在系统运行时禁用加速机制的能力可能会有所帮助（但这取决于工作负载）。

在某些情况下，确定性行为比性能或能耗（或两者）更重要，并且在系统运行时禁用加速的能力可能会有用。

要检查频率加速机制本身的影响，最好能够在不重新启动系统的情况下运行启用和禁用加速的测试。

运行基准测试时，可重现的结果很重要。由于加速功能取决于整个封装的负载，因此单线程性能可能会因此而发生变化，这有时可能会导致不可重现的结果。可以通过在运行对该问题敏感的基准测试之前禁用频率加速机制来避免这种情况。

旧版 AMD `cpb` 旋钮¶

AMD powernow-k8 缩放驱动程序支持一个与全局 boost 非常相似的 sysfs 旋钮。它用于禁用/启用某些 AMD 处理器的“核心性能加速”功能。

如果存在，则该旋钮位于 sysfs 中每个 CPUFreq 策略目录 (/sys/devices/system/cpu/cpufreq/policyX/) 中，称为 cpb，这表示更精细的控制接口。然而，实际的实现是在系统范围的基础上工作的，并且为一个策略设置该旋钮会导致同时为所有其他策略设置相同的值。

在支持其底层硬件功能的 AMD 处理器上仍然支持该旋钮，但它可能会在内核之外配置（通过 CONFIG_X86_ACPI_CPUFREQ_CPB 配置选项），并且全局 boost 旋钮始终存在。因此，始终可以使用 boost 旋钮代替 cpb 旋钮，强烈建议这样做，因为它与所有其他系统的工作方式更一致（并且 cpb 旋钮将来可能不再支持）。

对于任何没有底层硬件功能的处理器（例如，所有 Intel 处理器），即使设置了 CONFIG_X86_ACPI_CPUFREQ_CPB 配置选项，cpb 旋钮也永远不存在。

Linux 内核

目录

此页面

CPU 性能调节¶