2018年5月24日
第16卷，第2期

工作负载频率调节定律 - 推导与验证

工作负载可扩展性通过缩放因子呈级联关系。

Noor Mubeen，英特尔

许多处理器都公开了性能监控计数器，这些计数器有助于测量与工作负载相关的“生产性能”。生产性能通常用缩放因子表示，该术语指的是在时间窗口内停顿周期与无停顿周期相比的程度。工作负载的缩放因子也受频率选择调控器选择的时钟频率的影响。因此，在动态电压/频率调节或DVFS系统（例如英特尔Speed Shift¹）中，利用率、功耗和性能输出也是缩放因子及其变化的函数。一些调控算法确实以其调控理念固有的方式处理缩放因子。

本文介绍了与每个DVFS子系统级别的工作负载利用率调节相关的方程式。建立了频率、利用率和缩放因子（其本身随频率变化）之间的关系。这些方程式的验证被证明是棘手的，因为工作负载固有的利用率似乎也在调控样本的粒度上以未指定的方式变化。因此，应用了一种称为直方图脊迹的新方法。当将DVFS视为构建块时，量化调节影响至关重要。典型的应用包括DVFS调控器和/或影响系统利用率、功耗和性能的其他层。然而，这里的范围仅限于演示良好量化和验证的调节方程式。

工作负载调节

英特尔有三个与此主题相关的架构无关的寄存器

• A_perf。一个运行计数器，以执行时的实际时钟速率计数。此实际时钟频率可能会随着时间的推移而变化，具体取决于调控和/或其他算法。此寄存器仅在活动状态 (C0) 期间计数。

• M_perf。一个用于活动的运行计数器，以固定的 TSC（时间戳计数器）时钟速率计数。它仅在活动状态 (C0) 期间计数。

• P_perf。此计数器类似于 A_perf，不同之处在于，当活动由于某些依赖关系而停顿时，它不会计数，这很可能由另一个 IP 的时钟域（例如，内存）门控。

给定时间窗口中这些计数器的增量通常解释为以下内容

• 利用率。 U = ΔM_perf /ΔTSC

• 缩放因子。 S = ΔP_perf /ΔA_perf

理想情况下，如果活动没有停顿，则 P_perf = A_perf （即，缩放因子 S 将为 1）。在这种情况下，在给定时间窗口内完成活动所需的时间将简单地是在该窗口中实际频率的倒数。在大多数实际工作负载中，缩放因子会发生变化，并且通常小于 1。建立利用率、缩放因子和频率之间准确的方程式，使 DVFS 调控器能够做出明智的频率更改决策。

乍一看，工作负载调节问题可能类似于众所周知的阿姆达尔定律，后者处理与并行计算资源相关的工作负载加速。然而，阿姆达尔定律不能应用于此处，因为“可并行化因子”类比于“缩放因子”是不成立的——前者独立于正在调节的资源（即，并行处理器），而后者是正在调节的资源（即，频率）的函数。利用率在频率上的可扩展性通过缩放因子呈级联关系。

术语和假设

本文使用了以下术语

• 利用率或C0活动百分比是指时间窗口内活动（非空闲）时钟状态²。此处互换使用的负载和利用率指的是相同的属性。

• 可扩展活动 指的是操作的一部分（或百分比），其执行时间与频率成反比。

• 活动中的停顿 指的是操作的一部分（或百分比），其完成过程中涉及停顿。虽然较长的延迟实际上会导致C状态降级，但此处提及的指令停顿要短得多，并且发生在CPU处于C0活动状态时。

考虑DVFS系统上的频率调控器，在每个周期性时间窗口 T 更新频率。考虑当前时刻 t₀（“现在”），如图1所示。设刚刚完成的工作负载窗口 T 具有 t_act （或 t_a）作为其可扩展活动的一部分（即，t_act 表示活动的累积部分，该活动使处理器忙于执行，而无需任何依赖延迟或停顿）。设 T_stall （或 T_s）为子持续时间，描述经历的有效停顿（子系统间依赖性停顿）。另外，设 T_off （或 T_o）为DVFS子系统处于更深C状态的累积持续时间，这比C0状态低得多。T_off 和 T_stall 之间的根本区别在于，在后一种情况下，子系统仍然处于活动状态C0，同时经历非常短的依赖性停顿；而在前一种情况下，延迟足够大，以至于子系统进入短暂的更深C状态。

Workload Frequency Scaling law - Derivation and Verification

在给定的窗口中，负载执行活动时间是频率 f 的倒数。

或者，一般来说，在任何窗口中

英特尔生产性能³ 寄存器计数与 t_act 成比例的生产（非停顿）计数。将可扩展性 S 定义为生产计数 (P_perf) 与活动计数 (A_perf) 中增量的比率，得出以下通用方程式

此外，此窗口中的负载 l （C0 百分比）可以定义为

因果关系

考虑 t_-1 和 t₀ 之间的一个特定窗口 T。在这里，调控器已分配频率 f₀。如果调控器在同一窗口中分配了不同的频率 f'₀，则工作的可扩展部分（即，T_a）将是，例如 t'_a，从而从 t₀ 到 t'₀。出于实际目的，可以假定停顿周期与所选频率无关，因为停顿并非显式地依赖于本地子系统的时钟频率。因此，就它们与频率的因果关系而言，t 保持独立。类似地，在同一窗口内，要执行的生产（无停顿）指令的数量保持不变。具体而言，我们可以概括并暗示

停顿时间和生产周期计数与频率因果关系无关。

另请注意，频率和负载是因果关系考虑因素，在时间窗口内，而不是跨时间窗口。在推导的其余部分中，对频率变化的引用不是沿着时间流，而是如果频率是另一个频率的另一种可能的因果关系。

利用率（负载）到频率变化估计

工作负载可扩展性的一个重要方面与频率变化引起的负载变化程度有关。

如图2所示，窗口 ΔTSC 内 P_perf 和 A_perf 的采样增量值 ΔP₀,ΔA₀ 可以与 T 内的活动、停顿和关闭时间相关联。

现在，假设 DVFS 调控器已选择某个目标 f'₀ 而不是初始实际频率 f₀。要求是找到一个关系，该关系准确地表示由此因果关系导致的更改后的最终目标负载 l'₀。因此，导出时间 t₁ 的估计负载变化 l₁。

让频率为 f₀ 的因果窗口中的 A_perf 计数从当前 ΔA₀ 假设性地过渡到 ΔA'₀

ΔA'₀ = f'₀(t'_a + t'_s)

停顿时间不是本地子系统时钟的显式函数，停顿时间保持不变。换句话说，

停顿时间与频率因果关系无关。

t'_s = t_s

当我们用以下两个通用负载和缩放因子方程在时间 t_n 处求解时：

ΔA = f_n l_n ΔTSC/F_tsc

以及缩放因子为

求解得到

l'₀ = s'₀ l'₀ + l₀ - s₀l₀

或

现在，

同样，由于停顿时间不变性，

由于这不是迭代到下一个时间窗口，因此要执行的生产周期数保持不变。换句话说，

生产周期计数与频率因果关系无关。

ΔP'₀ = ΔP₀

这导致了缩放因子调节方程

此中间方程式定义了缩放因子本身在频率上的变化（调节）。进一步求解，我们得到

负载调节方程

在上面基于因果关系的推导中，该窗口中没有工作负载固有的变化。换句话说，如果从 f₀ 到 f'₀ 的因果关系是相邻未来时间窗口 t₁ 中的实际变化 f₁，并且上面的方程式用于估计这样的目标负载 l₁，那么与预期目标负载的任何偏差 (l_1actual - l'₀) 显然是在时间窗口 t₀ 到 t₁ 内累积的工作负载固有变化。由于 l_1actual 是已知的，因此可以计算与估计负载的任何偏差。估计的调节负载由此给出

类似地，估计的调节缩放因子近似由下式给出

在实际平台上的验证

上述最后两个方程式可以称为工作负载调节方程式。然而，在实际平台上凭经验验证它们并非易事。在单个周期的粒度上，可以确定右侧的三个参数 (f₀,f₁,s₀)；但如上所述，数学结果无法直接与该周期结束后的 l 进行比较；主要是因为传入负载本身可能会以离散样本为基础波动。然而，可以通过在不同频率下应用一系列直方图并跟踪其脊线来统计验证。使用这种直方图脊迹方法，验证了方程式的通用性。

首先，工作负载完全以固定频率运行。

工作负载 #1 是一个随机的基于浏览器的图形负载（图 3；https://webglsamples.org/multiple-views/multiple-views.html）

在捕获数据时，最好停止与分析中的工作负载无关的不需要的后台服务。此外，首选精确且轻量级的数据记录工具。在 Linux 系统上，英特尔 PSST⁴ 可以以固定、低且精确的开销完成日志记录。数据捕获持续时间为 100 秒，采样轮询周期为 20 毫秒。每个样本捕获的数据包括

• CPU 负载。

• 缩放因子。

• 钳位频率值。

在CPU的每个频率下重复整个运行，同时保持其他 DVFS 作为固定源（例如，Gfx 频率保持在中等但固定的值）。

捕获CPU缩放因子和利用率日志。在此示例中，时域分析不适用于收集可扩展性和利用率。相反，直方图分析识别在哪个桶中，对于给定的工作频率，负载点的数量最多。直方图的峰值表示给定频率下最有可能出现的负载值。在图 5 的示例数据中，大约 500 个样本（或总样本的 80%）发生在 33% 的负载下。即使频率是固定的，也很难从图 4 的时间图表中得出这样的推论。

对所有其他频率逐个迭代实验，以获得一系列直方图峰值，如图 6 所示。

使用来自上述实验集中的相同数据，可以绘制缩放因子的类似直方图脊迹，如图 7 所示。

缩放因子的调节

绘图工具用于创建图 7 中峰值直方图点（以缩放因子为单位）的地图视图，然后在图 8 中用红点绘制。在同一地图视图上，基于利用率和缩放因子的任何一个初始种子值，绘制了不同可能目标频率的缩放因子调节方程。图 8 显示了方程式与完整数据集之间的相关性。

负载调节

利用率的峰值直方图点的地图视图（图 6）在图 9 中用红点绘制。在同一地图视图上，基于利用率和缩放因子的一个初始种子值，绘制了不同可能目标频率的负载调节方程。

正如这些图中显示的结果所总结的那样，方程式的独立估计几乎与实际实验的统计结果完全吻合。此方法应用于多个其他工作负载（具有不同的缩放因子和负载级别），并如上所述进行了验证。

结论

本文详细阐述了时间窗口内利用率和缩放因子与可能的频率选择选择之间的因果关系。基于此，推导了通用的工作负载调节方程式，量化了利用率影响。通过在离散 DVFS 模块级别应用直方图脊迹方法来验证这些方程式。虽然仅详细介绍了 CPU 核心示例，但在其他 DVFS 模块（图形子模块）、其他工作负载和其他操作系统（Windows/Linux）上也观察到了类似的方程式一致性。方程式估计曲线与实际脊迹曲线非常准确地相关。这意味着利用率影响可以“预测”为在每个周期中都具有统计上的准确性，并且与它的任何偏差都可以归因于该周期中工作负载固有的利用率变化，并被视为适用于使用它的解决方案。

致谢

作者感谢英特尔同事的所有帮助——特别是，来自首席工程师 Harinarayanan Seshadri 和 Rajeev Muralidhar 以及软件工程师 B. M. Shravan K. 的宝贵意见。

参考文献

1. Howse, B. 2015. Examining Intel's new Speed Shift tech on Skylake: more responsive processors. AnandTech; examining-intel-skylake-speed-shift-more-responsive-processors.

2. Kidd, T. 2014. Power management states: P-states, C-states, and Package C-states. Intel Developer Zone; power-management-states-p-states-c-states-and-package-c-states.

3. Intel. Intel 64 and IA-32 Architectures, Software Developer's Manual, Volume 3B: System Programming Guide, Part 2; 64-ia-32-architectures-software-developer-vol-3b-part-2-manual.pdf.

4. Power Shaping and Stress Tool (PSST) for Intel Platforms. https://github.com/intel/psst

高能效软件
Eric Saxe
可电源管理的硬件可以帮助节省能源，但是软件开发人员可以做些什么来解决这个问题呢？
https://queue.org.cn/detail.cfm?id=1698225

使用非对称多核系统最大化电源效率
Alexandra Fedorova 等人。
非对称多核系统有望比传统的对称处理器节省更多能量。我们如何开发能够最大限度地发挥这种潜力的软件？
https://queue.org.cn/detail.cfm?id=1658422

手持设备上的能源管理
Marc A. Viredaz 等人。
无论其来源如何，所有手持设备都有相同的致命弱点：电池。
https://queue.org.cn/detail.cfm?id=957768

Noor Mubeen 是英特尔客户端研发部门的软件架构师，专注于电源、散热和能源管理方面的突破。过去，他曾在英特尔移动设备上设计散热管理。他拥有超过 17 年的经验，领域广泛，包括网络、存储文件系统和嵌入式设备。他是开源 GNU/Linux 爱好者。

最初发表于 Queue 第 16 卷，第 2 期—
在数字图书馆中评论本文

更多相关文章

David Collier-Brown - 你不了解关于应用程序性能的一切
您无需在每次遇到性能或容量规划问题时都进行全面基准测试。一个简单的测量将提供系统的瓶颈点：这个示例程序在每 CPU 每秒 8 个请求后会明显变慢。这通常足以告诉您最重要的事情：您是否会失败。

Peter Ward, Paul Wankadia, Kavita Guliani - 在 Google 重塑后端子集化
后端子集化对于降低成本很有用，甚至对于在系统限制内运行可能是必要的。十多年来，Google 使用确定性子集化作为其默认后端子集化算法，但尽管此算法平衡了每个后端任务的连接数，但确定性子集化具有高水平的连接流失。我们在 Google 的目标是设计一种具有减少连接流失的算法，该算法可以取代确定性子集化作为默认后端子集化算法。

Theo Schlossnagle - DevOps 世界中的监控
监控看起来可能非常令人难以承受。最重要的是要记住，完美永远不应该是更好的敌人。DevOps 使组织内部能够进行高度迭代的改进。如果您没有监控，请获取一些；获取任何东西。有总比没有好，如果您已经接受了 DevOps，那么您就已经注册了随着时间的推移使其变得更好。

Ulan Degenbaev, Jochen Eisinger, Manfred Ernst, Ross McIlroy, Hannes Payer - 空闲时间垃圾回收调度
Google 的 Chrome 网络浏览器致力于提供流畅的用户体验。动画将以 60 FPS（每秒帧数）更新屏幕，这为 Chrome 提供了大约 16.6 毫秒的时间来执行更新。在这 16.6 毫秒内，必须处理所有输入事件，必须执行所有动画，最后必须渲染帧。错过截止日期将导致丢帧。这些对用户可见，并会降低用户体验。此处将此类零星的动画伪影称为卡顿。本文介绍了 Chrome 使用的 JavaScript 引擎 V8 中实现的一种方法，用于在 Chrome 空闲时安排垃圾回收暂停。