intel_pstate CPU 性能缩放驱动程序¶
- 版权:
© 2017 英特尔公司
- 作者:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
一般信息¶
intel_pstate 是 Linux 内核中CPU 性能缩放子系统（CPUFreq）的一部分。它是用于 Sandy Bridge 和更新的几代英特尔处理器的缩放驱动程序。但请注意，某些处理器可能不受支持。[要理解 intel_pstate，有必要了解 CPUFreq 的工作原理，因此如果您尚未阅读 CPU 性能缩放，现在是阅读的时候了。]
对于 intel_pstate 支持的处理器，P 状态的概念比仅操作频率或操作性能点更广泛（有关更多信息，请参阅 Kristen Accardi 在 2015 年 LinuxCon Europe 上的演示文稿 [1]）。因此，intel_pstate 内部使用的 P 状态表示遵循硬件规范（有关详细信息，请参阅英特尔软件开发人员手册 [2]）。但是，CPUFreq 核心使用频率来标识 CPU 的操作性能点，并且频率包含在它公开的用户空间接口中，因此 intel_pstate 也将其 P 状态的内部表示映射到频率（幸运的是，该映射是明确的）。同时，由于其可能的尺寸，intel_pstate 向 CPUFreq 核心提供可用频率表是不切实际的，因此该驱动程序不会这样做。核心的某些功能因此受到限制。
由于 intel_pstate 使用的硬件 P 状态选择接口在逻辑 CPU 级别可用，因此驱动程序始终与各个 CPU 一起工作。因此，如果正在使用 intel_pstate，则每个 CPUFreq 策略对象都对应于一个逻辑 CPU，并且 CPUFreq 策略实际上等效于 CPU。特别是，这意味着每当相应的 CPU 脱机时，它们都会变为“不活动”状态，并且当它重新联机时需要重新初始化。
intel_pstate 不是模块化的，因此无法卸载，这意味着将早期配置时间参数传递给它的唯一方法是通过内核命令行。但是，可以通过 sysfs 在很大程度上调整其配置。在某些配置中，甚至可以通过 sysfs 注销它，这允许加载和注册另一个 CPUFreq 缩放驱动程序（请参阅下文）。
操作模式¶
intel_pstate 可以在两种不同的模式下运行，主动模式或被动模式。在主动模式下，它使用自己的内部性能缩放调速器算法，或者允许硬件自行进行性能缩放，而在被动模式下，它响应由通用 CPUFreq 调速器发出的请求，该调速器实现某种性能缩放算法。哪个模式生效取决于使用了哪些内核命令行选项以及处理器的功能。
主动模式¶
这是具有硬件管理的 P 状态 (HWP) 支持的处理器上的 intel_pstate 的默认操作模式。如果它在此模式下工作，则所有 CPUFreq 策略的 sysfs 中的 scaling_driver 策略属性都包含字符串“intel_pstate”。
在此模式下，驱动程序绕过 CPUFreq 的缩放调速器层，并为 P 状态选择提供自己的缩放算法。这些算法可以像通用缩放调速器一样应用于 CPUFreq 策略（即，通过 sysfs 中的 scaling_governor 策略属性）。[请注意，可以为不同的策略选择不同的 P 状态选择算法，但不建议这样做。]
它们不是通用的缩放调速器，但它们的名称与某些调速器的名称相同。而且，令人困惑的是，它们通常不会以与它们共享名称的通用调速器相同的方式工作。例如，intel_pstate 提供的 powersave P 状态选择算法不是通用 powersave 调速器的对应项（大致来说，它对应于 schedutil 和 ondemand 调速器）。
在主动模式下，intel_pstate 提供了两种 P 状态选择算法：powersave 和 performance。它们两种的运行方式取决于是否在处理器中启用了硬件管理的 P 状态 (HWP) 功能，并且可能取决于处理器型号。
默认使用哪种 P 状态选择算法取决于 CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE 内核配置选项。也就是说，如果设置了该选项，则默认情况下将使用 performance 算法，如果未设置该选项，则默认情况下将使用另一个算法。
具有 HWP 的主动模式¶
如果处理器支持 HWP 功能，它将在处理器初始化期间启用，并且之后无法禁用。可以通过在命令行中传递 intel_pstate=no_hwp 参数给内核来避免启用它。
如果 HWP 功能已启用，intel_pstate 依赖于处理器自行选择 P 状态，但它仍然可以为处理器的内部 P 状态选择逻辑提供提示。这些提示取决于应用于给定策略（或与其对应的 CPU）的 P 状态选择算法。
即使 P 状态的选择由处理器自动执行，intel_pstate 也会在这种模式下向 CPU 调度器注册利用率更新回调。但是，它们不用于运行 P 状态选择算法，而是用于定期更新当前 CPU 频率信息，以便从 sysfs 中的 scaling_cur_freq 策略属性中获取。
HWP + performance¶
在此配置中，intel_pstate 会将 0 写入处理器的能量-性能偏好 (EPP) 旋钮（如果支持）或其能量-性能偏置 (EPB) 旋钮（否则），这意味着处理器的内部 P 状态选择逻辑预计将完全专注于性能。
这将覆盖来自 sysfs 接口的 EPP/EPB 设置（请参阅下面的 能量与性能提示）。此外，在此配置中，任何尝试通过 sysfs 将 EPP/EPB 更改为 0（“性能”）以外的值的尝试都将被拒绝。
此外，在此配置中，处理器内部 P 状态选择逻辑可用的 P 状态范围始终被限制为上限（即驱动程序允许使用的最大 P 状态）。
HWP + powersave¶
在此配置中，intel_pstate 会将处理器的能量-性能偏好 (EPP) 旋钮（如果支持）或其能量-性能偏置 (EPB) 旋钮（否则）设置为先前通过 sysfs 设置的值（或平台固件设置的默认值）。这通常会导致处理器内部的 P 状态选择逻辑不那么注重性能。
无 HWP 的活动模式¶
对于不支持 HWP 功能的处理器或在命令行中将 intel_pstate=no_hwp 参数传递给内核时，此操作模式是可选的。如果在命令行中将 intel_pstate=active 参数传递给内核，则在这些情况下使用活动模式。在此模式下，intel_pstate 可能会拒绝与它未识别的处理器一起工作。[请注意，intel_pstate 永远不会拒绝与任何启用 HWP 功能的处理器一起工作。]
在此模式下，intel_pstate 会向 CPU 调度器注册利用率更新回调，以便运行 P 状态选择算法，即 powersave 或 performance，具体取决于 sysfs 中的 scaling_governor 策略设置。从 sysfs 中的 scaling_cur_freq 策略属性获取的当前 CPU 频率信息也由这些利用率更新回调定期更新。
performance¶
在没有 HWP 的情况下，此 P 状态选择算法始终相同，与处理器型号和平台配置无关。
每次更新给定 CPU 的驱动程序配置（例如，通过 sysfs）时，它都会选择允许使用的最大 P 状态，但受通过 sysfs 设置的限制约束。
如果设置了 CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE 内核配置选项，则这是默认的 P 状态选择算法。
powersave¶
在没有 HWP 的情况下，此 P 状态选择算法类似于通用 schedutil 缩放调速器实现的算法，不同之处在于它使用的利用率指标基于来自 CPU 反馈寄存器的数字。它通常选择与当前 CPU 利用率成比例的 P 状态。
当 CPU 调度器调用时，驱动程序的给定 CPU 的利用率更新回调会运行此算法，但频率不超过每 10 毫秒一次。与 performance 情况一样，如果新的 P 状态与当前 P 状态相同，则不会触及硬件配置。
如果未设置 CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE 内核配置选项，则这是默认的 P 状态选择算法。
被动模式¶
对于不支持硬件管理的 P 状态 (HWP) 的处理器，这是 intel_pstate 的默认操作模式。如果将 intel_pstate=passive 参数传递给内核，则始终使用此模式，无论给定处理器是否支持 HWP。[请注意，如果 intel_pstate=no_hwp 设置未与 intel_pstate=active 组合使用，则会导致驱动程序以被动模式启动。] 与没有 HWP 支持的活动模式一样，在此模式下，如果通过内核命令行阻止启用 HWP，intel_pstate 可能会拒绝与它未识别的处理器一起工作。
如果驱动程序在此模式下工作，则所有 CPUFreq 策略的 sysfs 中的 scaling_driver 策略属性包含字符串 “intel_cpufreq”。然后，驱动程序的行为类似于常规的 CPUFreq 缩放驱动程序。也就是说，它会在必要时由通用缩放调速器调用，以便与硬件通信以更改 CPU 的 P 状态（特别是，schedutil 调速器可以直接从调度器上下文中调用它）。
在此模式下，intel_pstate 可以与 sysfs 中 scaling_available_governors 策略属性列出的所有（通用）缩放调速器一起使用（并且不使用上述 P 状态选择算法）。然后，它负责配置与 CPU 相对应的策略对象，并向 CPUFreq 核心（以及附加到策略对象的缩放调速器）提供有关硬件支持的最大和最小工作频率的准确信息（包括所谓的“睿频”频率范围）。换句话说，在被动模式下，intel_pstate 将所有可用 P 状态范围暴露给 CPUFreq 核心。但是，在此模式下，驱动程序不会向 CPU 调度器注册利用率更新回调，并且 scaling_cur_freq 信息来自 CPUFreq 核心（并且是由当前缩放调速器为给定策略选择的最后一个频率）。
睿频 P 状态支持¶
在大多数情况下，intel_pstate 可用的整个 P 状态范围可以分为两个子范围，它们对应于不同类型的处理器行为，高于和低于一个边界，该边界将在下面称为“睿频阈值”。
高于睿频阈值的 P 状态称为“睿频 P 状态”，它们所属的整个 P 状态子范围称为“睿频范围”。这些名称与 Turbo Boost 技术相关，该技术允许多核处理器在有足够的功率并且不会导致处理器封装的热包络超过的情况下，机会性地增加一个或多个内核的 P 状态。
具体而言，如果软件将 CPU 内核的 P 状态设置在睿频范围内（即高于睿频阈值），则允许处理器接管该内核的性能缩放控制，并在将来将其置于其选择的睿频 P 状态。但是，不同代的处理器对该权限的解释不同。也就是说，Sandy Bridge 处理器世代永远不会使用高于软件为给定内核设置的最后一个 P 状态的任何 P 状态，即使它在睿频范围内，而所有较新的处理器世代都会将其视为使用睿频范围内的任何 P 状态的许可证，即使高于软件设置的 P 状态。换句话说，在这些处理器上，设置睿频范围内的任何 P 状态都将使处理器能够将给定的内核置于所有睿频 P 状态中，包括它认为合适的最高支持 P 状态。
睿频 P 状态的一个重要特性是它们不可持续。更准确地说，不能保证任何 CPU 能够无限期地保持在这些状态中的任何一种状态，因为处理器封装内的功率分配可能会随着时间而变化，或者如果睿频 P 状态使用时间过长，可能会超过其设计的散热范围。
反过来，低于睿频阈值的 P 状态通常是可持续的。事实上，如果软件设置了其中一个 P 状态，则除非在热应力或违反功耗限制的情况下（例如，如果同时为同一封装中的另一个 CPU 设置了更高的 P 状态，则仍可以使用更高的 P 状态），否则处理器不会将其更改为较低的 P 状态。
一些处理器允许多个核心同时处于睿频 P 状态，但它们可以设置的最大 P 状态通常取决于同时运行的核心数量。3 个核心可以同时设置的最大睿频 P 状态通常低于 2 个核心对应的最大 P 状态，而 2 个核心的最大 P 状态又通常低于 1 个核心可以设置的最大睿频 P 状态。因此，单核最大睿频 P 状态是整体支持的最大值。
最大支持的睿频 P 状态、睿频阈值（最大支持的非睿频 P 状态）和最小支持的 P 状态是特定于处理器型号的，可以通过读取处理器的特定于型号的寄存器 (MSR) 来确定。此外，一些处理器支持可配置 TDP（热设计功耗）功能，并且当该功能启用时，睿频阈值实际上会变为一个可配置的值，可以由平台固件设置。
与 ACPI 表中的 _PSS 对象不同，intel_pstate 始终将整个可用的 P 状态范围（包括整个睿频范围）暴露给 CPUFreq 核心以及（在被动模式下）暴露给通用缩放调速器。这通常会导致在使用 intel_pstate 时，相比基于 ACPI 的 CPU 性能缩放，更频繁地设置睿频 P 状态（有关更多信息，请参阅下面的内容）。
此外，由于 intel_pstate 始终知道真实的睿频阈值（即使在处理器中启用了可配置 TDP 功能），因此其在 sysfs 中的 no_turbo 属性（在下面描述）应该在所有情况下都按预期工作（也就是说，如果设置为禁用睿频 P 状态，则应该始终阻止 intel_pstate 使用它们）。
处理器支持¶
为了处理给定的处理器，intel_pstate 需要知道关于它的许多不同信息，包括
通常，获取这些信息的方法是特定于处理器型号或系列的。虽然通常可以从处理器本身获取所有这些信息（使用特定于型号的寄存器），但在某些情况下，还需要查阅硬件手册才能获取到这些信息。
因此，intel_pstate 中有一个支持的处理器列表，并且如果检测到的处理器不在该列表中，则驱动程序初始化将失败，除非它支持 HWP 功能。[对于所有支持 HWP 功能的处理器，获取上面列出的所有信息的接口都是相同的，这就是为什么 intel_pstate 可以与它们全部工作的原因。]
sysfs 中的用户空间接口¶
全局属性¶
intel_pstate 在 sysfs 中公开了几个全局属性（文件）来控制其在系统级别的功能。它们位于 /sys/devices/system/cpu/intel_pstate/ 目录中，并影响所有 CPU。
如果将 intel_pstate=per_cpu_perf_limits 参数传递给命令行中的内核，则其中一些属性将不存在。
max_perf_pct驱动程序允许设置的最大 P 状态，以最大支持的性能水平（支持的最高睿频 P 状态）的百分比表示。
如果内核命令行中存在
intel_pstate=per_cpu_perf_limits参数，则不会公开此属性。min_perf_pct驱动程序允许设置的最小 P 状态，以最大支持的性能水平（支持的最高睿频 P 状态）的百分比表示。
如果内核命令行中存在
intel_pstate=per_cpu_perf_limits参数，则不会公开此属性。num_pstates处理器支持的 P 状态数量（包括 0 到 255），包括睿频和非睿频 P 状态（请参阅睿频 P 状态支持）。
仅当所有 CPU 的此属性值相同时，才显示此属性。
此属性的值不受下面描述的
no_turbo设置的影响。此属性是只读的。
turbo_pct睿频范围大小与支持的整个 P 状态范围大小的比率，以百分比表示。
仅当所有 CPU 的此属性值相同时，才显示此属性。
此属性是只读的。
no_turbo如果设置（等于 1），则不允许驱动程序设置任何睿频 P 状态（请参阅睿频 P 状态支持）。如果未设置（等于 0，这是默认值），则驱动程序可以设置睿频 P 状态。[请注意，
intel_pstate不支持通用的boost属性（某些其他缩放驱动程序支持该属性），该属性由此属性替换。]此属性不会影响提供给
CPUFreq核心并通过策略接口公开的最大支持频率值，但它会影响每个策略 P 状态限制的最大可能值（有关详细信息，请参阅下面的策略属性的解释）。hwp_dynamic_boost仅当
intel_pstate在处理器中启用 启用 HWP 功能的活动模式时，才显示此属性。如果设置（等于 1），则当先前等待 I/O 的任务被选择在给定的逻辑 CPU 上运行时，会导致最小 P 状态限制动态增加一小段时间（此机制的目的是提高性能）。此设置对最小 P 状态限制直接设置为最高非睿频 P 状态或高于该状态的逻辑 CPU 没有影响。
status驱动程序的操作模式：“active”、“passive” 或 “off”。
- “active”
驱动程序处于功能状态，并且处于活动模式。
- “passive”
驱动程序处于功能状态，并且处于被动模式。
- “off”
驱动程序不处于功能状态（它没有注册为
CPUFreq核心的缩放驱动程序）。
可以写入此属性以更改驱动程序的操作模式或取消注册它。写入它的字符串必须是它的可能值之一，并且如果成功，则写入将导致驱动程序切换到该字符串表示的操作模式，或者在 “off” 情况下取消注册。[实际上，从活动模式切换到被动模式或反之会导致驱动程序被注销并再次注册，其中具有不同的回调集，因此它的所有设置（全局设置和每个策略的设置）都会重置为它们的默认值，可能会取决于目标操作模式。]
energy_efficiency此属性仅在具有与 Kaby Lake 或 Coffee Lake 台式机 CPU 型号匹配的 CPU 的平台上存在。默认情况下，如果启用 HWP，则在这些 CPU 型号上禁用能效优化。启用能效优化可能会限制最大工作频率，无论是否启用 HWP 功能。如果启用了 HWP，则优化仅在睿频频率范围内完成。如果没有启用 HWP，则在整个可用频率范围内完成优化。将此属性设置为 “1” 可启用能效优化，设置为 “0” 可禁用能效优化。
策略属性的解释¶
在 intel_pstate 作为当前缩放驱动程序时，在 CPU 性能缩放中描述的某些 CPUFreq 策略属性的解释是特殊的，并且通常取决于驱动程序的操作模式。
首先，cpuinfo_max_freq、cpuinfo_min_freq 和 scaling_cur_freq 属性的值是通过将特定于处理器的乘数应用于 intel_pstate 使用的内部 P 状态表示生成的。此外，scaling_max_freq 和 scaling_min_freq 属性的值受到驱动程序允许设置的最大 P 状态对应的频率的限制。
如果设置了 no_turbo 全局属性，则不允许驱动程序使用睿频 P 状态，因此 scaling_max_freq 和 scaling_min_freq 的最大值将限制为最大非睿频 P 状态频率。因此，如果 scaling_max_freq 和 scaling_min_freq 之前高于该值，则设置 no_turbo 会导致 scaling_max_freq 和 scaling_min_freq 下降到该值。但是，取消设置 no_turbo 后，scaling_max_freq 和 scaling_min_freq 的旧值将恢复，除非在设置 no_turbo 之后写入了这些属性。
如果未设置 no_turbo，则 scaling_max_freq 和 scaling_min_freq 的最大可能值对应于最大支持的睿频 P 状态，这也两种情况下 cpuinfo_max_freq 的值。
接下来，如果 intel_pstate 在活动模式下工作，则以下策略属性具有特殊含义
scaling_available_governorsintel_pstate提供的 P 状态选择算法列表。scaling_governor当前与给定策略一起使用的
intel_pstate提供的 P 状态选择算法。scaling_cur_freq对于该 CPU 的 CPU 调度程序最后两次调用驱动程序的利用率更新回调之间的时间间隔，由给定策略表示的 CPU 的平均 P 状态的频率。
如果处理器中启用了 HWP 功能，则还会显示一个策略属性
base_frequency显示 CPU 的基本频率。高于此频率的任何频率都将在睿频频率范围内。
这些属性在被动模式下的含义与其他缩放驱动程序相同。
此外，intel_pstate 的 scaling_driver 属性值取决于驱动程序的操作模式。具体来说，它要么是“intel_pstate”（在主动模式下），要么是 “intel_cpufreq”（在被动模式下）。
P 状态限制的协调¶
intel_pstate 允许通过两种方式设置 P 状态限制：借助 max_perf_pct 和 min_perf_pct 全局属性，或者通过 scaling_max_freq 和 scaling_min_freq CPUFreq 策略属性。这些限制之间的协调基于以下规则，而与驱动程序的当前操作模式无关。
所有 CPU 都受全局限制的影响（即，没有一个 CPU 可以被要求运行速度高于全局最大值，也没有一个 CPU 可以被要求运行速度低于全局最小值）。
每个单独的 CPU 都受其自身的每个策略限制的影响（即，它不能被要求运行速度高于其自身的每个策略最大值，也不能被要求运行速度低于其自身的每个策略最小值）。有效性能取决于平台是否支持每核心 P 状态、是否启用了超线程以及来自其他 CPU 的当前性能请求。当平台不支持每核心 P 状态时，如果其他 CPU 在此时请求更高的性能，则有效性能可能高于在 CPU 上设置的策略限制。即使支持每核心 P 状态，当启用超线程时，如果兄弟 CPU 请求更高的性能，则其他兄弟 CPU 将获得高于其策略限制的性能。
全局和每个策略的限制可以独立设置。
在启用 HWP 功能的主动模式下，每当限制发生变化时，会将产生的有效值写入硬件寄存器，以便请求其内部 P 状态选择逻辑始终将 P 状态设置在这些限制内。否则，这些限制将由缩放调速器（在被动模式下）和驱动程序在每次为 CPU 设置新的 P 状态之前考虑。
此外，如果将 intel_pstate=per_cpu_perf_limits 命令行参数传递给内核，则根本不会公开 max_perf_pct 和 min_perf_pct，并且设置限制的唯一方法是使用策略属性。
能耗与性能提示¶
如果在处理器中启用了硬件管理的 P 状态 (HWP)，则在 sysfs 中的每个 CPUFreq 策略目录中都存在其他属性，旨在允许用户空间帮助 intel_pstate 通过将重点放在性能或能效上，或者介于两者之间的某个位置来调整处理器的内部 P 状态选择逻辑。它们是：
energy_performance_preference给定策略（或由其表示的 CPU）的能耗与性能提示的当前值。
可以通过写入此属性来更改提示。
energy_performance_available_preferences可以写入
energy_performance_preference属性的字符串列表。它们表示不同的能耗与性能提示，并且应该是不言自明的，除了
default表示平台固件设置的任何提示值。
写入 energy_performance_preference 属性的字符串在内部转换为写入处理器能耗-性能偏好 (EPP) 旋钮（如果支持）或其能耗-性能偏置 (EPB) 旋钮的整数值。如果存在 EPP 功能，也可以写入 0 到 255 之间的正整数值。如果不存在 EPP 功能，则不支持写入此属性的整数值。在这种情况下，用户可以使用“/sys/devices/system/cpu/cpu*/power/energy_perf_bias”接口。
[请注意，任务可能会通过调度程序的负载平衡算法从一个 CPU 迁移到另一个 CPU，如果为这些 CPU 设置了不同的能耗与性能提示，可能会导致不良后果。为了避免此类问题，最好为所有 CPU 设置相同的能耗与性能提示，或者将每个可能对此敏感的任务固定到特定的 CPU。]
intel_pstate 与 acpi-cpufreq¶
在 intel_pstate 支持的大多数系统上，平台固件提供的 ACPI 表包含 _PSS 对象，这些对象返回可用于 CPU 性能缩放的信息（有关 _PSS 对象以及它们返回的信息的格式的详细信息，请参阅 ACPI 规范[3]）。
ACPI _PSS 对象返回的信息由 acpi-cpufreq 缩放驱动程序使用。在 intel_pstate 支持的系统上，acpi-cpufreq 驱动程序使用相同的硬件 CPU 性能缩放接口，但它可以使用的 P 状态集受到 _PSS 输出的限制。
在这些系统上，每个 _PSS 对象都会返回相应的 CPU 支持的 P 状态列表，该列表基本上是同一系统上 intel_pstate 可以使用的 P 状态范围的子集，但有一个例外：整个睿频范围在该列表中用一项（最上面的一项）表示。按照惯例，_PSS 为该项返回的频率比它列出的最高非睿频 P 状态的频率高 1 MHz，但为其返回的相应 P 状态表示（遵循硬件规范）与支持的最大睿频 P 状态匹配（或特殊值 255，基本上表示“尽可能高”）。
_PSS 返回的 P 状态列表反映在 acpi-cpufreq 提供给 CPUFreq 核心和缩放调速器的可用频率表中，并且它报告的最小和最大支持频率也来自该列表。特别是，鉴于上述睿频范围的特殊表示，这意味着 acpi-cpufreq 报告的最大支持频率比 _PSS 列出的最高支持的非睿频 P 状态的频率高 1 MHz，这当然会影响缩放调速器做出的决策，除了 powersave 和 performance。
例如，如果给定的调速器尝试选择与估计的 CPU 负载成比例的频率，并将 100% 的负载映射到最大支持频率（可能乘以一个常数），那么如果使用 acpi-cpufreq 作为缩放驱动程序，它将倾向于选择低于睿频阈值的 P 状态，因为在这种情况下，睿频范围对应于它可以使用的频段的一小部分（1 MHz 与 1 GHz 或更多）。因此，它仅在最高负载时进入睿频范围，而其他可能受益于以睿频频率运行的 50% 以上的负载将改为给出非睿频 P 状态。
在支持可配置 TDP 功能的系统上，可能会出现与此相关的另一个问题，该功能允许平台固件设置睿频阈值。也就是说，如果这没有与 _PSS 返回的 P 状态列表正确协调，则这些列表中可能有多个与睿频 P 状态对应的项，并且在避免睿频范围时（如果需要或必要）可能会出现问题。通常，为了避免整体使用睿频 P 状态，acpi-cpufreq 只是避免使用 _PSS 列出的最上面的状态，但是当它返回的列表中有其他睿频 P 状态时，这就不够了。
除了上述情况外，acpi-cpufreq 的工作方式类似于被动模式下的 intel_pstate，只是它可以设置的 P 状态数量仅限于 ACPI _PSS 对象列出的那些。
intel_pstate 的内核命令行选项¶
可以使用几个内核命令行选项将早期配置时的参数传递给 intel_pstate，以强制执行其特定行为。 所有这些选项都必须以 intel_pstate= 前缀开头。
disable即使处理器支持
intel_pstate，也不要将其注册为调频驱动程序。active在主动模式下注册
intel_pstate以启动。passive在被动模式下注册
intel_pstate以启动。force即使在给定系统上首选
acpi-cpufreq，也注册intel_pstate作为调频驱动程序。这可能会阻止某些依赖 ACPI P 状态信息的平台功能（例如散热控制和功率限制）按预期工作，因此应谨慎使用。
此选项不适用于不受
intel_pstate支持的处理器，也不适用于使用pcc-cpufreq调频驱动程序而不是acpi-cpufreq的平台。no_hwp即使处理器支持硬件管理的 P 状态（HWP）功能，也不要启用该功能。
hwp_only仅当处理器支持硬件管理的 P 状态（HWP）功能时，才注册
intel_pstate作为调频驱动程序。support_acpi_ppc考虑 ACPI
_PPC性能限制。如果 FADT（固定 ACPI 描述表）中首选的电源管理配置文件设置为“企业服务器”或“性能服务器”，则默认情况下会考虑 ACPI
_PPC限制，此选项无效。per_cpu_perf_limits使用每个逻辑 CPU 的 P 状态限制（有关详细信息，请参阅P 状态限制的协调）。
诊断和调优¶
跟踪事件¶
有两个静态跟踪事件可用于 intel_pstate 诊断。 其中一个是 CPUFreq 通常使用的 cpu_frequency 跟踪事件，另一个是 intel_pstate 特有的 pstate_sample 跟踪事件。 只有当 intel_pstate 在主动模式下工作时，才会触发这两个事件。
如果内核通常配置为支持事件跟踪，则可以使用以下 shell 命令序列来启用它们并查看其输出
# cd /sys/kernel/tracing/
# echo 1 > events/power/pstate_sample/enable
# echo 1 > events/power/cpu_frequency/enable
# cat trace
gnome-terminal--4510 [001] ..s. 1177.680733: pstate_sample: core_busy=107 scaled=94 from=26 to=26 mperf=1143818 aperf=1230607 tsc=29838618 freq=2474476
cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2
如果 intel_pstate 在被动模式下工作，则 cpu_frequency 跟踪事件将由 schedutil 调频管理程序（对于它所附加的策略）或由 CPUFreq 内核（对于具有其他调频管理程序的策略）触发。
ftrace¶
ftrace 接口可用于 intel_pstate 的低级诊断。 例如，要检查调用设置 P 状态的函数的频率，可以将 ftrace 过滤器设置为 intel_pstate_set_pstate()
# cd /sys/kernel/tracing/
# cat available_filter_functions | grep -i pstate
intel_pstate_set_pstate
intel_pstate_cpu_init
...
# echo intel_pstate_set_pstate > set_ftrace_filter
# echo function > current_tracer
# cat trace | head -15
# tracer: function
#
# entries-in-buffer/entries-written: 80/80 #P:4
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
Xorg-3129 [000] ..s. 2537.644844: intel_pstate_set_pstate <-intel_pstate_timer_func
gnome-terminal--4510 [002] ..s. 2537.649844: intel_pstate_set_pstate <-intel_pstate_timer_func
gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func
<idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func