0001 .. SPDX-License-Identifier: GPL-2.0
0002 .. include:: ../disclaimer-zh_CN.rst
0003
0004 :Original: Documentation/scheduler/sched-energy.rst
0005
0006 :翻译:
0007
0008 唐艺舟 Tang Yizhou <tangyeechou@gmail.com>
0009
0010 ============
0011 能量感知调度
0012 ============
0013
0014 1. 简介
0015 -------
0016
0017 能量感知调度（EAS）使调度器有能力预测其决策对CPU所消耗的能量的影响。EAS依靠
0018 一个能量模型（EM）来为每个任务选择一个节能的CPU，同时最小化对吞吐率的影响。
0019 本文档致力于介绍介绍EAS是如何工作的，它背后的主要设计决策是什么，以及使其运行
0020 所需的条件细节。
0021
0022 在进一步阅读之前，请注意，在撰写本文时::
0023
0024 /!\ EAS不支持对称CPU拓扑的平台 /!\
0025
0026 EAS只在异构CPU拓扑结构（如Arm大小核，big.LITTLE）上运行。因为在这种情况下，
0027 通过调度来节约能量的潜力是最大的。
0028
0029 EAS实际使用的EM不是由调度器维护的，而是一个专门的框架。关于这个框架的细节和
0030 它提供的内容，请参考其文档（见Documentation/power/energy-model.rst）。
0031
0032
0033 2. 背景和术语
0034 -------------
0035
0036 从一开始就说清楚定义:
0037 - 能量 = [焦耳] （比如供电设备上的电池提供的资源）
0038 - 功率 = 能量/时间 = [焦耳/秒] = [瓦特]
0039
0040 EAS的目标是最小化能量消耗，同时仍能将工作完成。也就是说，我们要最大化::
0041
0042 性能 [指令数/秒]
0043 ----------------
0044 功率 [瓦特]
0045
0046 它等效于最小化::
0047
0048 能量 [焦耳]
0049 -----------
0050 指令数
0051
0052 同时仍然获得“良好”的性能。当前调度器只考虑性能目标，因此该式子本质上是一个
0053 可选的优化目标，它同时考虑了两个目标：能量效率和性能。
0054
0055 引入EM的想法是为了让调度器评估其决策的影响，而不是盲目地应用可能仅在部分
0056 平台有正面效果的节能技术。同时，EM必须尽可能的简单，以最小化调度器的时延
0057 影响。
0058
0059 简而言之，EAS改变了CFS任务分配给CPU的方式。当调度器决定一个任务应该在哪里
0060 运行时（在唤醒期间），EM被用来在不损害系统吞吐率的情况下，从几个较好的候选
0061 CPU中挑选一个经预测能量消耗最优的CPU。EAS的预测依赖于对平台拓扑结构特定元素
0062 的了解，包括CPU的“算力”，以及它们各自的能量成本。
0063
0064
0065 3. 拓扑信息
0066 -----------
0067
0068 EAS（以及调度器的剩余部分）使用“算力”的概念来区分不同计算吞吐率的CPU。一个
0069 CPU的“算力”代表了它在最高频率下运行时能完成的工作量，且这个值是相对系统中
0070 算力最大的CPU而言的。算力值被归一化为1024以内，并且可与由实体负载跟踪
0071 （PELT）机制算出的利用率信号做对比。由于有算力值和利用率值，EAS能够估计一个
0072 任务/CPU有多大/有多忙，并在评估性能与能量时将其考虑在内。CPU算力由特定体系
0073 结构实现的arch_scale_cpu_capacity()回调函数提供。
0074
0075 EAS使用的其余平台信息是直接从能量模型（EM）框架中读取的。一个平台的EM是一张
0076 表，表中每项代表系统中一个“性能域”的功率成本。（若要了解更多关于性能域的细节，
0077 见Documentation/power/energy-model.rst）
0078
0079 当调度域被建立或重新建立时，调度器管理对拓扑代码中EM对象的引用。对于每个根域
0080 （rd），调度器维护一个与当前rd->span相交的所有性能域的单向链表。链表中的每个
0081 节点都包含一个指向EM框架所提供的结构体em_perf_domain的指针。
0082
0083 链表被附加在根域上，以应对独占的cpuset的配置。由于独占的cpuset的边界不一定与
0084 性能域的边界一致，不同根域的链表可能包含重复的元素。
0085
0086 示例1
0087 让我们考虑一个有12个CPU的平台，分成3个性能域，（pd0，pd4和pd8），按以下
0088 方式组织::
0089
0090 CPUs: 0 1 2 3 4 5 6 7 8 9 10 11
0091 PDs: |--pd0--|--pd4--|---pd8---|
0092 RDs: |----rd1----|-----rd2-----|
0093
0094 现在，考虑用户空间决定将系统分成两个独占的cpusets，因此创建了两个独立的根域，
0095 每个根域包含6个CPU。这两个根域在上图中被表示为rd1和rd2。由于pd4与rd1和rd2
0096 都有交集，它将同时出现于附加在这两个根域的“->pd”链表中:
0097
0098 * rd1->pd: pd0 -> pd4
0099 * rd2->pd: pd4 -> pd8
0100
0101 请注意，调度器将为pd4创建两个重复的链表节点（每个链表中各一个）。然而这
0102 两个节点持有指向同一个EM框架的共享数据结构的指针。
0103
0104 由于对这些链表的访问可能与热插拔及其它事件并发发生，因此它们受RCU锁保护，就像
0105 被调度器操控的拓扑结构体中剩下字段一样。
0106
0107 EAS同样维护了一个静态键（sched_energy_present），当至少有一个根域满足EAS
0108 启动的所有条件时，这个键就会被启动。在第6节中总结了这些条件。
0109
0110
0111 4. 能量感知任务放置
0112 -------------------
0113
0114 EAS覆盖了CFS的任务唤醒平衡代码。在唤醒平衡时，它使用平台的EM和PELT信号来选择节能
0115 的目标CPU。当EAS被启用时，select_task_rq_fair()调用find_energy_efficient_cpu()
0116 来做任务放置决定。这个函数寻找在每个性能域中寻找具有最高剩余算力（CPU算力 - CPU
0117 利用率）的CPU，因为它能让我们保持最低的频率。然后，该函数检查将任务放在新CPU相较
0118 依然放在之前活动的prev_cpu是否可以节省能量。
0119
0120 如果唤醒的任务被迁移，find_energy_efficient_cpu()使用compute_energy()来估算
0121 系统将消耗多少能量。compute_energy()检查各CPU当前的利用率情况，并尝试调整来
0122 “模拟”任务迁移。EM框架提供了API em_pd_energy()计算每个性能域在给定的利用率条件
0123 下的预期能量消耗。
0124
0125 下面详细介绍一个优化能量消耗的任务放置决策的例子。
0126
0127 示例2
0128 让我们考虑一个有两个独立性能域的（伪）平台，每个性能域含有2个CPU。CPU0和CPU1
0129 是小核，CPU2和CPU3是大核。
0130
0131 调度器必须决定将任务P放在哪个CPU上，这个任务的util_avg = 200（平均利用率），
0132 prev_cpu = 0（上一次运行在CPU0）。
0133
0134 目前CPU的利用率情况如下图所示。CPU 0-3的util_avg分别为400、100、600和500。
0135 每个性能域有三个操作性能值（OPP）。与每个OPP相关的CPU算力和功率成本列在能量
0136 模型表中。P的util_avg在图中显示为"PP"::
0137
0138 CPU util.
0139 1024 - - - - - - - Energy Model
0140 +-----------+-------------+
0141 | Little | Big |
0142 768 ============= +-----+-----+------+------+
0143 | Cap | Pwr | Cap | Pwr |
0144 +-----+-----+------+------+
0145 512 =========== - ##- - - - - | 170 | 50 | 512 | 400 |
0146 ## ## | 341 | 150 | 768 | 800 |
0147 341 -PP - - - - ## ## | 512 | 300 | 1024 | 1700 |
0148 PP ## ## +-----+-----+------+------+
0149 170 -## - - - - ## ##
0150 ## ## ## ##
0151 ------------ -------------
0152 CPU0 CPU1 CPU2 CPU3
0153
0154 Current OPP: ===== Other OPP: - - - util_avg (100 each): ##
0155
0156
0157 find_energy_efficient_cpu()将首先在两个性能域中寻找具有最大剩余算力的CPU。
0158 在这个例子中是CPU1和CPU3。然后，它将估算，当P被放在它们中的任意一个时，系统的
0159 能耗，并检查这样做是否会比把P放在CPU0上节省一些能量。EAS假定OPPs遵循利用率
0160 （这与CPUFreq监管器schedutil的行为一致。关于这个问题的更多细节，见第6节）。
0161
0162 **情况1. P被迁移到CPU1**::
0163
0164 1024 - - - - - - -
0165
0166 Energy calculation:
0167 768 ============= * CPU0: 200 / 341 * 150 = 88
0168 * CPU1: 300 / 341 * 150 = 131
0169 * CPU2: 600 / 768 * 800 = 625
0170 512 - - - - - - - ##- - - - - * CPU3: 500 / 768 * 800 = 520
0171 ## ## => total_energy = 1364
0172 341 =========== ## ##
0173 PP ## ##
0174 170 -## - - PP- ## ##
0175 ## ## ## ##
0176 ------------ -------------
0177 CPU0 CPU1 CPU2 CPU3
0178
0179
0180 **情况2. P被迁移到CPU3**::
0181
0182 1024 - - - - - - -
0183
0184 Energy calculation:
0185 768 ============= * CPU0: 200 / 341 * 150 = 88
0186 * CPU1: 100 / 341 * 150 = 43
0187 PP * CPU2: 600 / 768 * 800 = 625
0188 512 - - - - - - - ##- - -PP - * CPU3: 700 / 768 * 800 = 729
0189 ## ## => total_energy = 1485
0190 341 =========== ## ##
0191 ## ##
0192 170 -## - - - - ## ##
0193 ## ## ## ##
0194 ------------ -------------
0195 CPU0 CPU1 CPU2 CPU3
0196
0197 **情况3. P依旧留在prev_cpu/CPU0**::
0198
0199 1024 - - - - - - -
0200
0201 Energy calculation:
0202 768 ============= * CPU0: 400 / 512 * 300 = 234
0203 * CPU1: 100 / 512 * 300 = 58
0204 * CPU2: 600 / 768 * 800 = 625
0205 512 =========== - ##- - - - - * CPU3: 500 / 768 * 800 = 520
0206 ## ## => total_energy = 1437
0207 341 -PP - - - - ## ##
0208 PP ## ##
0209 170 -## - - - - ## ##
0210 ## ## ## ##
0211 ------------ -------------
0212 CPU0 CPU1 CPU2 CPU3
0213
0214 从这些计算结果来看，情况1的总能量最低。所以从节约能量的角度看，CPU1是最佳候选
0215 者。
0216
0217 大核通常比小核更耗电，因此主要在任务不适合在小核运行时使用。然而，小核并不总是比
0218 大核节能。举例来说，对于某些系统，小核的高OPP可能比大核的低OPP能量消耗更高。因此，
0219 如果小核在某一特定时间点刚好有足够的利用率，在此刻被唤醒的小任务放在大核执行可能
0220 会更节能，尽管它在小核上运行也是合适的。
0221
0222 即使在大核所有OPP都不如小核OPP节能的情况下，在某些特定条件下，令小任务运行在大核
0223 上依然可能节能。事实上，将一个任务放在一个小核上可能导致整个性能域的OPP提高，这将
0224 增加已经在该性能域运行的任务的能量成本。如果唤醒的任务被放在一个大核上，它的执行
0225 成本可能比放在小核上更高，但这不会影响小核上的其它任务，这些任务将继续以较低的OPP
0226 运行。因此，当考虑CPU消耗的总能量时，在大核上运行一个任务的额外成本可能小于为所有
0227 其它运行在小核的任务提高OPP的成本。
0228
0229 上面的例子几乎不可能以一种通用的方式得到正确的结果；同时，对于所有平台，在不知道
0230 系统所有CPU每个不同OPP的运行成本时，也无法得到正确的结果。得益于基于EM的设计，
0231 EAS应该能够正确处理这些问题而不会引发太多麻烦。然而，为了确保对高利用率场景的
0232 吞吐率造成的影响最小化，EAS同样实现了另外一种叫“过度利用率”的机制。
0233
0234
0235 5. 过度利用率
0236 -------------
0237
0238 从一般的角度来看，EAS能提供最大帮助的是那些涉及低、中CPU利用率的使用场景。每当CPU
0239 密集型的长任务运行，它们将需要所有的可用CPU算力，调度器将没有什么办法来节省能量同时
0240 又不损害吞吐率。为了避免EAS损害性能，一旦CPU被使用的算力超过80%，它将被标记为“过度
0241 利用”。只要根域中没有CPU是过度利用状态，负载均衡被禁用，而EAS将覆盖唤醒平衡代码。
0242 EAS很可能将负载放置在系统中能量效率最高的CPU而不是其它CPU上，只要不损害吞吐率。
0243 因此，负载均衡器被禁用以防止它打破EAS发现的节能任务放置。当系统未处于过度利用状态时，
0244 这样做是安全的，因为低于80%的临界点意味着：
0245
0246 a. 所有的CPU都有一些空闲时间，所以EAS使用的利用率信号很可能准确地代表各种任务
0247 的“大小”。
0248 b. 所有任务，不管它们的nice值是多大，都应该被提供了足够多的CPU算力。
0249 c. 既然有多余的算力，那么所有的任务都必须定期阻塞/休眠，在唤醒时进行平衡就足够
0250 了。
0251
0252 只要一个CPU利用率超过80%的临界点，上述三个假设中至少有一个是不正确的。在这种情况下，
0253 整个根域的“过度利用”标志被设置，EAS被禁用，负载均衡器被重新启用。通过这样做，调度器
0254 又回到了在CPU密集的条件下基于负载的算法做负载均衡。这更好地尊重了任务的nice值。
0255
0256 由于过度利用率的概念在很大程度上依赖于检测系统中是否有一些空闲时间，所以必须考虑
0257 （比CFS）更高优先级的调度类（以及中断）“窃取”的CPU算力。像这样，对过度使用率的检测
0258 不仅要考虑CFS任务使用的算力，还需要考虑其它调度类和中断。
0259
0260
0261 6. EAS的依赖和要求
0262 ------------------
0263
0264 能量感知调度依赖系统的CPU具有特定的硬件属性，以及内核中的其它特性被启用。本节列出
0265 了这些依赖，并对如何满足这些依赖提供了提示。
0266
0267
0268 6.1 - 非对称CPU拓扑
0269 ^^^^^^^^^^^^^^^^^^^
0270
0271
0272 如简介所提，目前只有非对称CPU拓扑结构的平台支持EAS。通过在运行时查询
0273 SD_ASYM_CPUCAPACITY_FULL标志位是否在创建调度域时已设置来检查这一要求是否满足。
0274
0275 参阅Documentation/scheduler/sched-capacity.rst以了解在sched_domain层次结构
0276 中设置此标志位所需满足的要求。
0277
0278 请注意，EAS并非从根本上与SMP不兼容，但在SMP平台上还没有观察到明显的节能。这一
0279 限制可以在将来进行修改，如果被证明不是这样的话。
0280
0281
0282 6.2 - 当前的能量模型
0283 ^^^^^^^^^^^^^^^^^^^^
0284
0285 EAS使用一个平台的EM来估算调度决策对能量的影响。因此，你的平台必须向EM框架提供
0286 能量成本表，以启动EAS。要做到这一点，请参阅文档
0287 Documentation/power/energy-model.rst中的独立EM框架部分。
0288
0289 另请注意，调度域需要在EM注册后重建，以便启动EAS。
0290
0291 EAS使用EM对能量使用率进行预测决策，因此它在检查任务放置的可能选项时更加注重
0292 差异。对于EAS来说，EM的功率值是以毫瓦还是以“抽象刻度”为单位表示并不重要。
0293
0294
0295
0296 6.3 - 能量模型复杂度
0297 ^^^^^^^^^^^^^^^^^^^^
0298
0299 任务唤醒路径是时延敏感的。当一个平台的EM太复杂（太多CPU，太多性能域，太多状态
0300 等），在唤醒路径中使用它的成本就会升高到不可接受。能量感知唤醒算法的复杂度为：
0301
0302 C = Nd * (Nc + Ns)
0303
0304 其中：Nd是性能域的数量；Nc是CPU的数量；Ns是OPP的总数（例如：对于两个性能域，
0305 每个域有4个OPP，则Ns = 8）。
0306
0307 当调度域建立时，复杂性检查是在根域上进行的。如果一个根域的复杂度C恰好高于完全
0308 主观设定的EM_MAX_COMPLEXITY阈值（在本文写作时，是2048），则EAS不会在此根域
0309 启动。
0310
0311 如果你的平台的能量模型的复杂度太高，EAS无法在这个根域上使用，但你真的想用，
0312 那么你就只剩下两个可能的选择：
0313
0314 1. 将你的系统拆分成分离的、较小的、使用独占cpuset的根域，并在每个根域局部
0315 启用EAS。这个方案的好处是开箱即用，但缺点是无法在根域之间实现负载均衡，
0316 这可能会导致总体系统负载不均衡。
0317 2. 提交补丁以降低EAS唤醒算法的复杂度，从而使其能够在合理的时间内处理更大
0318 的EM。
0319
0320
0321 6.4 - Schedutil监管器
0322 ^^^^^^^^^^^^^^^^^^^^^
0323
0324 EAS试图预测CPU在不久的将来会在哪个OPP下运行，以估算它们的能量消耗。为了做到
0325 这一点，它假定CPU的OPP跟随CPU利用率变化而变化。
0326
0327 尽管在实践中很难对这一假设的准确性提供硬性保证（因为，举例来说硬件可能不会做
0328 它被要求做的事情），相对于其他CPUFreq监管器，schedutil至少_请求_使用利用率
0329 信号计算的频率。因此，与EAS一起使用的唯一合理的监管器是schedutil，因为它是
0330 唯一一个在频率请求和能量预测之间提供某种程度的一致性的监管器。
0331
0332 不支持将EAS与schedutil之外的任何其它监管器一起使用。
0333
0334
0335 6.5 刻度不变性使用率信号
0336 ^^^^^^^^^^^^^^^^^^^^^^^^
0337
0338 为了对不同的CPU和所有的性能状态做出准确的预测，EAS需要频率不变的和CPU不变的
0339 PELT信号。这些信号可以通过每个体系结构定义的arch_scale{cpu,freq}_capacity()
0340 回调函数获取。
0341
0342 不支持在没有实现这两个回调函数的平台上使用EAS。
0343
0344
0345 6.6 多线程（SMT）
0346 ^^^^^^^^^^^^^^^^^
0347
0348 当前实现的EAS是不感知SMT的，因此无法利用多线程硬件节约能量。EAS认为线程是独立的
0349 CPU，这实际上对性能和能量消耗都是不利的。
0350
0351 不支持在SMT上使用EAS。
