The Concept of CPU Performance Scaling(待续)

… |struct cpufreq_policy| replace:: :c:type:struct cpufreq_policy <cpufreq_policy>
… |intel_pstate| replace:: :doc:intel_pstate <intel_pstate>

=======================
CPU Performance Scaling

::

Copyright © 2017 Intel Corp., Rafael J. Wysocki rafael.j.wysocki@intel.com

The Concept of CPU Performance Scaling

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

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

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

CPU Performance Scaling in Linux

Linux内核通过“CPUFreq”（CPU频率调节）子系统支持CPU性能调节，该子系统由三层代码组成：core, scaling governors 和 scaling drivers。

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

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

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

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

然而，这种观察可能不适用于基于硬件本身提供的信息的性能调节算法，例如通过反馈寄存器，因为该信息通常特定于其来自的硬件接口，并且可能不容易在抽象的平台中表示。因此，CPUFreq允许调节驱动程序绕过governors 并实现自己的性能缩放算法。intel_pstate 调节驱动程序就是这么干的。

CPUFreq Policy Objects

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

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

CPUFreqcore为系统中每个CPU维护一个指向cpufreq_policy对象的指针，包括当前处于离线状态的CPU。 如果多个CPU共享相同的硬件P状态控制接口，则它们所有指针指向相同的 cpufreq_policy对象。

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

CPU Initialization

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

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

在任何情况下，调用CPUFreqcore来记录它到目前为止尚未看到的任何逻辑CPU，只要它准备好处理该CPU。 [注意，逻辑CPU可以是物理单核处理器，或多核处理器中的单核，或物理处理器或处理器核中的硬件线程。在下文中，“CPU”始终表示“逻辑CPU”，除非另有明确说明，并且“处理器”一词用于表示可能包括多个逻辑CPU的物理部分。

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

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

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

该回调预计将为使用CPU调度程序的属于给定policy的所有在线CPU注册每CPU利用率更新回调。 利用率更新回调将在重要事件（如在每次scheduler tick发生时任务入队和出队）被CPU调度程序调用，或者通常在CPU利用率可能发生变化时（从调度程序的角度）。 期望它们执行确定用于给定policy 所需的P状态，并调用scaling driver以根据P状态对硬件进行改变。 scaling driver可以直接从调度程序上下文调用，也可以通过内核线程或工作队列异步调用，具体取决于scaling driver和governor的配置和功能。

对于非新的policy 对象采取类似的步骤，但之前是“非活动的”，这意味着属于它们的所有CPU都处于离线状态。 在这种情况下唯一的实际区别是CPUFreq核心将尝试使用先前变为“非活动”（并且现在重新初始化）的policy 一起使用的 scaling governor，而不是默认governor。

反过来，如果先前离线的CPU变为在线，但是与其共享policy 对象的其他一些CPU已经在线，则根本不需要重新初始化policy 对象。在这种情况下，只需要重新启动 scaling governor，以便可以考虑新的在线CPU。这是通过按顺序为整个policy调用governor的- > stop和- > start（）回调来实现的。

如前所述，intel_pstatescaling driver绕过CPUFreq的scaling governor层，并自己提供选择P状态的算法。 因此，如果intel_pstate 被使用，则不会将scaling governor附加到新policy 对象。 相反，调用驱动程序的- > setpolicy（）回调来为每个policy 注册每个CPU利用率更新回调。 这些回调由CPU调度程序以与scaling governors相同的方式调用，但在intel_pstate中调用。 它们都确定要使用的P状态，并相应地从调度程序上下文中相应地更改硬件配置。

在CPU初始化期间创建的policy 对象以及与其关联的其他数据结构在取消注册scaling driver时会被拆除（例如，在卸载包含它的内核模块时发生）或者在属于给定策略的最后一个CPU取消注册时。

Policy Interface in sysfs

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

该目录对由CPUFreqcore维护的每个policy 对象包含一个policyX子目录（其中X表示一个整数）。每个policyX目录被相关的所有CPU在/sys/devices/system/cpu/cpuY/下cpufreq（其中Y和由“X”表示的那个不同）符号链接指向。policyX目录位于/ sys / devices / system / cpu / cpufreq，每个目录都包含特定于policy的属性（文件）来控制相应policy对象的CPUFreq行为（对所有与之关联的CPU）。

其中一些属性是通用的。它们由CPUFreqcore创建，它们的行为通常不依赖于正在使用的scaling driver 以及给定policy附加的scaling governor。一些scaling drivers还将“特定于驱动程序”的属性添加到“sysfs”中的策略目录中，以控制驱动程序特定于policy方面的行为。

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

affected_cpus
属于该policy 的在线CPU列表（即共享由policyX策略对象表示的硬件性能调节接口）。

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

可能是某些（通常是无意的）BIOS设置限制，在服务处理器或其他基于BIOS / HW的机制的作用下。

这不包括可通过通用thermel驱动发现的ACPI thermal 限制。

如果使用的scaling driver不支持此属性，则此属性不存在。

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

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

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

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

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

如果未知或者已知但太高以至于scaling driver不能与ondemand_ governor一起使用，则从该属性读取将返回-1。

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

scaling_available_governors
内核中存在的CPUFreqscaling governors列表，可以附加到policy或（如果正在使用intel_pstate scaling驱动程序）驱动程序提供的可应用于policy的scaling algorithms列表。

[请注意，某些governors是模块化的，可能需要为其加载内核模块以使其可用并由此属性列出。]

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

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

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

scaling_driver
目前正在使用的scaling driver。

scaling_governor
当前附加到此policy的scaling governor或（如果正在使用intel_pstate scaling driver）由当前应用于此策略的驱动程序提供的scaling governor。

此属性是可读写的，写入它将导致新的scaling governor 附加到此policy或由scaling driver提供的调节算法应用于它（在intel_pstate 情况中），写入此属性的字符串（必须是上面描述的scaling_available_governors属性列出的名称之一）。

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

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

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

该属性是可读写的，并且向其写入表示非负整数的字符串将导致设置新的限制（它不能高于scaling_max_freq属性的值）。.

scaling_setspeed
仅当userspace_ scaling governor附加到给定策略时，此属性才有效。

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

Generic Scaling Governors

CPUFreq提供了可用于所有scaling drivers的通用scaling governors。 如前所述，它们中的每一个都实现了单独的，可能是参数化的性能调节算法。

Scaling governors 附加到policy对象，并且不同的scaling governors可以同时处理不同的policy对象（尽管在某些情况下可能导致不理想的结果）。

可以在sysfs中的scaling_governorpolicy属性的帮助下随时更改给定policy对象的scaling governor 。

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

performance

当附加到policy对象时，此governor会在“scaling_max_freq”策略限制内为该策略请求最高频率。

当policy的governor设置为“performance”时，还有每当scaling_max_freq或scaling_min_freq策略限制发生变化时，请求进行一次。

powersave

当附加到policy对象时，此governor会在“scaling_min_freq”策略限制内为该策略请求最低频率。

当policy的governor设置为powersave时，还有每当之后scaling_max_freq或scaling_min_freq策略限制改变时，请求进行一次。

userspace

这个governor本身并没有做任何事情。 相反，它允许用户空间通过写入该策略的scaling_setspeed属性来为其附加的policy设置CPU频率。

schedutil

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

它完全在调度程序上下文中运行，但在某些情况下，它可能需要在确定对给定policy更改CPU频率时异步调用scaling driver（这取决于驱动程序是否能够在调度程序上下文更改CPU频率）。

此governor对特定CPU的操作取决于调用该CPU的利用率更新回调的调度类。 如果它由RT或deadline调度类调用，则调控器会将频率增加到允许的最大值频率（即scaling_max_freq策略限制）。 反过来，如果它由CFS调度类调用，则governor将使用给定CPU的root控制组的每实体负载跟踪（PELT）度量作为CPU利用率评估（参见Per-entity load trackingLWN.net文章，描述了PELT机制）。 然后，根据公式计算新的要应用的CPU频率

f = 1.25 * ``f_0`` * ``util`` / ``max``

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

该governor还采用了一种机制，允许它暂时提高CPU频率，以用于最近等待I / O的任务，称为“IO-wait boosting”。 当调度程序将SCHED_CPUFREQ_IOWAIT标志传递给governor回调时会发生这种情况，这会导致频率立即上升到允许的最大值，然后回退到上面公式返回的值。

此governor只公开一个可调参数：

rate_limit_us
在两次连续运行的governor计算之间必须经过的最短时间（以微秒为单位）（默认值：scaling driver的转换延迟的1000倍）。

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

这个governor通常被认为是旧的ondemand_和conservativegovernor（如下所述）的替代品，因为它更简单，并且与CPU调度器更紧密地集成。它在CPU上下文切换方面的开销和类似的不太重要，它使用调度程序自己的CPU利用率度量，因此原则上它的决定不应该与调度程序其他部分做出的决定相矛盾。

ondemand

此governor使用CPU负载作为CPU频率选择指标。

为了评估当前的CPU负载，它测量连续调用其工作程序之间所经过的时间，并计算给定CPU不空闲时间的分数。非空闲（活动）时间与总CPU时间的比率被视为负载的估计。

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

此governor的工作程序必须在进程上下文中运行，因此它将被异步调用（通过工作队列），并在必要时更新CPU P状态。因此，来自此governor的调度程序上下文开销极小，但它会额外导致CPU上下文切换相对经常发生，并且由它触发的CPU P状态更新可能相对不规则。此外，它运行减少CPU空闲时间的代码影响了其自身的CPU负载指标（即使CPU空闲时间仅因此而略微降低）。

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

此governor公开以下可调参数：

sampling_rate
This is how often the governor’s worker routine should run, in
microseconds.

Typically, it is set to values of the order of 10000 (10 ms).  Its
default value is equal to the value of ``cpuinfo_transition_latency``
for each policy this governor is attached to (but since the unit here
is greater by 1000, this means that the time represented by
``sampling_rate`` is 1000 times greater than the transition latency by
default).

If this tunable is per-policy, the following shell command sets the time
represented by it to be 750 times as high as the transition latency::

# echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate

up_threshold
If the estimated CPU load is above this value (in percent), the governor
will set the frequency to the maximum value allowed for the policy.
Otherwise, the selected frequency will be proportional to the estimated
CPU load.

ignore_nice_load
If set to 1 (default 0), it will cause the CPU load estimation code to
treat the CPU time spent on executing tasks with “nice” levels greater
than 0 as CPU idle time.

This may be useful if there are tasks in the system that should not be
taken into account when deciding what frequency to run the CPUs at.
Then, to make that happen it is sufficient to increase the "nice" level
of those tasks above 0 and set this attribute to 1.

sampling_down_factor
Temporary multiplier, between 1 (default) and 100 inclusive, to apply to
the sampling_rate value if the CPU load goes above up_threshold.

This causes the next execution of the governor's worker routine (after
setting the frequency to the allowed maximum) to be delayed, so the
frequency stays at the maximum level for a longer time.

Frequency fluctuations in some bursty workloads may be avoided this way
at the cost of additional energy spent on maintaining the maximum CPU
capacity.

powersave_bias
Reduction factor to apply to the original frequency target of the
governor (including the maximum value used when the up_threshold
value is exceeded by the estimated CPU load) or sensitivity threshold
for the AMD frequency sensitivity powersave bias driver
(:file:drivers/cpufreq/amd_freq_sensitivity.c), between 0 and 1000
inclusive.

If the AMD frequency sensitivity powersave bias driver is not loaded,
the effective frequency to apply is given by

	f * (1 - ``powersave_bias`` / 1000)

where f is the governor's original frequency target.  The default value
of this attribute is 0 in that case.

If the AMD frequency sensitivity powersave bias driver is loaded, the
value of this attribute is 400 by default and it is used in a different
way.

On Family 16h (and later) AMD processors there is a mechanism to get a
measured workload sensitivity, between 0 and 100% inclusive, from the
hardware.  That value can be used to estimate how the performance of the
workload running on a CPU will change in response to frequency changes.

The performance of a workload with the sensitivity of 0 (memory-bound or
IO-bound) is not expected to increase at all as a result of increasing
the CPU frequency, whereas workloads with the sensitivity of 100%
(CPU-bound) are expected to perform much better if the CPU frequency is
increased.

If the workload sensitivity is less than the threshold represented by
the ``powersave_bias`` value, the sensitivity powersave bias driver
will cause the governor to select a frequency lower than its original
target, so as to avoid over-provisioning workloads that will not benefit
from running at higher CPU frequencies.

conservative

This governor uses CPU load as a CPU frequency selection metric.

It estimates the CPU load in the same way as the ondemand_ governor described
above, but the CPU frequency selection algorithm implemented by it is different.

Namely, it avoids changing the frequency significantly over short time intervals
which may not be suitable for systems with limited power supply capacity (e.g.
battery-powered). To achieve that, it changes the frequency in relatively
small steps, one step at a time, up or down - depending on whether or not a
(configurable) threshold has been exceeded by the estimated CPU load.

This governor exposes the following tunables:

freq_step
Frequency step in percent of the maximum frequency the governor is
allowed to set (the scaling_max_freq policy limit), between 0 and
100 (5 by default).

This is how much the frequency is allowed to change in one go.  Setting
it to 0 will cause the default frequency step (5 percent) to be used
and setting it to 100 effectively causes the governor to periodically
switch the frequency between the ``scaling_min_freq`` and
``scaling_max_freq`` policy limits.

down_threshold
Threshold value (in percent, 20 by default) used to determine the
frequency change direction.

If the estimated CPU load is greater than this value, the frequency will
go up (by ``freq_step``).  If the load is less than this value (and the
``sampling_down_factor`` mechanism is not in effect), the frequency will
go down.  Otherwise, the frequency will not be changed.

sampling_down_factor
Frequency decrease deferral factor, between 1 (default) and 10
inclusive.

It effectively causes the frequency to go down ``sampling_down_factor``
times slower than it ramps up.

Frequency Boost Support

Background

Some processors support a mechanism to raise the operating frequency of some
cores in a multicore package temporarily (and above the sustainable frequency
threshold for the whole package) under certain conditions, for example if the
whole chip is not fully utilized and below its intended thermal or power budget.

Different names are used by different vendors to refer to this functionality.
For Intel processors it is referred to as “Turbo Boost”, AMD calls it
“Turbo-Core” or (in technical documentation) “Core Performance Boost” and so on.
As a rule, it also is implemented differently by different vendors. The simple
term “frequency boost” is used here for brevity to refer to all of those
implementations.

The frequency boost mechanism may be either hardware-based or software-based.
If it is hardware-based (e.g. on x86), the decision to trigger the boosting is
made by the hardware (although in general it requires the hardware to be put
into a special state in which it can control the CPU frequency within certain
limits). If it is software-based (e.g. on ARM), the scaling driver decides
whether or not to trigger boosting and when to do that.

The boost File in sysfs

This file is located under :file:/sys/devices/system/cpu/cpufreq/ and controls
the “boost” setting for the whole system. It is not present if the underlying
scaling driver does not support the frequency boost mechanism (or supports it,
but provides a driver-specific interface for controlling it, like
|intel_pstate|).

If the value in this file is 1, the frequency boost mechanism is enabled. This
means that either the hardware can be put into states in which it is able to
trigger boosting (in the hardware-based case), or the software is allowed to
trigger boosting (in the software-based case). It does not mean that boosting
is actually in use at the moment on any CPUs in the system. It only means a
permission to use the frequency boost mechanism (which still may never be used
for other reasons).

If the value in this file is 0, the frequency boost mechanism is disabled and
cannot be used at all.

The only values that can be written to this file are 0 and 1.

Rationale for Boost Control Knob

The frequency boost mechanism is generally intended to help to achieve optimum
CPU performance on time scales below software resolution (e.g. below the
scheduler tick interval) and it is demonstrably suitable for many workloads, but
it may lead to problems in certain situations.

For this reason, many systems make it possible to disable the frequency boost
mechanism in the platform firmware (BIOS) setup, but that requires the system to
be restarted for the setting to be adjusted as desired, which may not be
practical at least in some cases. For example:

1. Boosting means overclocking the processor, although under controlled
   conditions. Generally, the processor’s energy consumption increases
   as a result of increasing its frequency and voltage, even temporarily.
   That may not be desirable on systems that switch to power sources of
   limited capacity, such as batteries, so the ability to disable the boost
   mechanism while the system is running may help there (but that depends on
   the workload too).

2. In some situations deterministic behavior is more important than
   performance or energy consumption (or both) and the ability to disable
   boosting while the system is running may be useful then.

3. To examine the impact of the frequency boost mechanism itself, it is useful
   to be able to run tests with and without boosting, preferably without
   restarting the system in the meantime.

4. Reproducible results are important when running benchmarks. Since
   the boosting functionality depends on the load of the whole package,
   single-thread performance may vary because of it which may lead to
   unreproducible results sometimes. That can be avoided by disabling the
   frequency boost mechanism before running benchmarks sensitive to that
   issue.

Legacy AMD cpb Knob

The AMD powernow-k8 scaling driver supports a sysfs knob very similar to
the global boost one. It is used for disabling/enabling the “Core
Performance Boost” feature of some AMD processors.

If present, that knob is located in every CPUFreq policy directory in
sysfs (:file:/sys/devices/system/cpu/cpufreq/policyX/) and is called
cpb, which indicates a more fine grained control interface. The actual
implementation, however, works on the system-wide basis and setting that knob
for one policy causes the same value of it to be set for all of the other
policies at the same time.

That knob is still supported on AMD processors that support its underlying
hardware feature, but it may be configured out of the kernel (via the
:c:macro:CONFIG_X86_ACPI_CPUFREQ_CPB configuration option) and the global
boost knob is present regardless. Thus it is always possible use the
boost knob instead of the cpb one which is highly recommended, as that
is more consistent with what all of the other systems do (and the cpb knob
may not be supported any more in the future).

The cpb knob is never present for any processors without the underlying
hardware feature (e.g. all Intel ones), even if the
:c:macro:CONFIG_X86_ACPI_CPUFREQ_CPB configuration option is set.

… _Per-entity load tracking: https://lwn.net/Articles/531853/