1.简介
能量感知调度（EAS）使调度程序能够预测其决策对 CPU 消耗的电量的影响。 EAS 依赖于 CPU 的能量模型 (EM) 来为每个任务选择省电的 CPU，同时要求对执行任务的吞吐量的影响最小。 本文档介绍 EAS 的工作原理、它背后的主要设计决策是什么，并说明让它运行所需的条件。
EAS 仅在异构 CPU 架构上（例如 Arm big.LITTLE）上运行，因为这是通过调度器节省电量的效果最大的地方。
2. 术语
能量 = [焦耳]（移动设备上的电池、电能）
功率 = 能量/时间 = [焦耳/秒] = [瓦特]
EAS的目标使用最小的能量完成所需要执行的动作，所以我们主要考量下面两个参数：
performance [ ints / s] / power [w] 最大值
energy [j] / instruction 最小值
在上述两个指标合适的同时仍然获得优异的性能表现，这种思路考虑了两个方面：能效和性能。
引入 EM 背后的想法是让调度程序能够评估其决策的影响，而不是盲目使用可能仅对某些平台有效果的低功耗手段。同时，EM 模型必须尽可能简单，以减小调度程序延迟的效果。
简而言之，EAS 改变了 CFS 任务分配给 CPU 的方式。当调度程序决定当前任务应该在哪里运行时（在唤醒期间），EM 用来打破了几个好的 CPU 候选者之间的平等关系，选择一个最佳的候选CPU运行当前任务：会产生最少的电量消耗而不牺牲系统的吞吐量的目标。 EAS 做出的预测依赖于有关平台架构的特性，其中包括 CPU 的“容量”及其各自的能源成本。
3.具体实现细节
EAS（以及调度程序的其余部分）使用“容量”的概念来区分具有不同计算吞吐量的 CPU。 CPU 的“容量”表示与系统中最强大的 CPU 相比，它以最高频率运行时可以完成的工作量。CPU容量值在0~1024 范围内进行归一化处理，同时与由PELT 机制计算的任务与 CPU 的利用率信号相对比。通过容量和利用率值，EAS 能够估计任务有多大或者CPU有多繁忙，并在评估性能与能源的权衡时考虑到这一点。
EAS 使用的其余必须的信息可以直接从能源模型 (EM) 框架中读取。平台的 EM 由系统中每个“性能域”的功率成本表组成。
下面试一个12个CPU的平台 分成了3个性能域，3个性能域也可以分成两个根域
4. 能量感知任务选择目标CPU
EAS 调度算法基于 CFS 任务唤醒平衡代码。它使用平台的 EM 和 PELT 信息在调度时机唤醒期间选择节能目标 CPU。当启用 EAS 时，select_task_rq_fair() 调用 find_energy_efficient_cpu() 来执行放置决策。此函数会在每个性能域中寻找具有最高备用容量（CPU 容量 – CPU 利用率）的 CPU，因为它可以让我们保持最低频率去运行任务。然后，该函数检查将任务迁移到候选CPU与将其留在之前的CPU 上相比是否可以节省电量。
find_energy_efficient_cpu() 使用 compute_energy() 来估计如果唤醒任务被迁移，系统将消耗多少电量。 compute_energy() 查看 CPU 的当前利用率情况并对其进行调整以“模拟”任务迁移。 EM 框架提供 em_pd_energy() API，该 API 计算给定使用环境下每个性能域的预期能耗。
让我们假设一个虚拟平台，它有 2 个独立的性能域，每个域由两个 CPU 组成。 CPU0 和 CPU1 是little CPU； CPU2 和 CPU3 为big CPU。
调度程序必须决定当前任务P迁移到哪个CPU进行执： 工作量负载util_avg = 200 和 prev_cpu = 0 。
CPU 的当前利用率情况如下图所示。 CPU 0-3 的 工作量负载 util_avg 分别为 400、100、600 和 500。每个性能域都有三个操作性能点 (OPP)。 能源模型表中列出了与每个 OPP 相关的 CPU 容量和电力成本。 P 的 util_avg 在下图中显示为“PP”
find_energy_efficient_cpu() 将首先在两个性能域中查找具有最大备用容量的 CPU。 在本例中，CPU1 和 CPU3。 然后它会估计系统的能量，如果 P 放在它们中的任何一个上，并检查与将 P 放在 CPU0 上相比是否会节省一些能量。
大核 CPU 通常比小 核CPU 更耗电，因此主要在任务不适合小 CPU 时才迁移到大核CPU使用。然而，小 核CPU 并不总是比大 核CPU 更节能。例如，对于某些系统，小核CPU 的高 OPP 可能比大核 CPU 的最低 OPP 节能。因此，如果小 CPU 在特定时间点恰好有足够的利用率，那么在那个时刻醒来的小任务可能会更好地在大侧执行以节省能量，即使它适合小侧.
并且即使在大CPU的所有OPP都比小CPU的能源效率低的情况下，使用大核CPU执行小任务在特定条件下仍然可以节省能源。事实上，将一个任务放在一个小的 CPU 上会导致整个性能域的 OPP 提高，这将增加已经在那里运行的任务的成本。如果将唤醒任务放在大核CPU 上，其自身的执行成本可能会比在小 CPU 上运行时更高，但不会影响小 CPU 的其他任务，这些任务将继续以较低的 OPP 运行。因此，在考虑 CPU 消耗的总能量时，在大内核上运行该任务的额外成本可能小于在小 CPU 上为所有其他任务提高 OPP 的成本。
如果不知道在系统中的所有 CPU 上不同 OPP 下的运行的成本，上面的示例几乎不可能以通用方式正确完成，并广泛适用于所有平台。由于基于 EM 的设计，EAS 可以正确应对它们而不会遇到太多麻烦。但是，为了确保对高利用率场景的吞吐量影响最小，EAS 还实施了另一种称为“过度利用率”的机制
5.过度使用
从一般的角度来看，EAS 最有帮助的用例是那些涉及轻/中 程度CPU 利用率的场景。当运行长时间受 CPU 限制的任务时，这些任务将需要所有可用的 CPU 容量，并且调度程序无法在不严重损害吞吐量的情况下节省能源。为了避免 EAS 影响性能，一旦 CPU 使用率超过其计算容量的 80%，就会被标记为“过度使用”。只要根域中没有 CPU 被过度使用，负载平衡就会被禁用，并且 EAS 会覆盖唤醒平衡代码。如果可以在不损害吞吐量的情况下完成，EAS 可能会比其他系统加载更多能效 CPU。因此，负载平衡器被禁用以防止它破坏 EAS 发现的节能任务迁移。当系统没有过度使用时，这样做是安全的，因为低于 80% 的临界点意味着：所有 CPU 上都有一些空闲时间，因此 EAS 使用的利用率信号很可能准确地表示系统中各种任务的“大小”；所有任务都应该已经提供了足够的 CPU 容量，无论它们的值如何；由于有空闲容量，所有任务都必须定期阻塞/休眠，并且在唤醒时进行平衡就足够了。
一旦一个 CPU 超过 80% 的临界点，上述三个假设中的至少一个就会变得不正确。在这种情况下，整个根域的“过度使用”标志被引发，EAS 被禁用，负载平衡器被重新启用。通过这样做，调度程序回退到基于负载的算法，以在 CPU 受限的条件下进行唤醒和负载平衡。这更好地尊重了任务的美好价值。
由于过度使用的概念在很大程度上依赖于检测系统中是否存在空闲时间，因此必须考虑被更高（比 CFS）调度类（以及 IRQ）“窃取”的 CPU 容量。因此，过度使用的检测不仅考虑了 CFS 任务使用的容量，还考虑了其他调度类和 IRQ 使用的容量。
6. EAS 的依赖和要求
由于过度使用的概念在很大程度上依赖于检测系统中是否存在空闲时间，因此必须考虑被更高（比 CFS）调度类（以及 IRQ）“窃取”的 CPU 容量。因此，过度使用的检测不仅考虑了 CFS 任务使用的容量，还考虑了其他调度类和 IRQ 使用的容量。
6.1 – 非对称 CPU 架构
如简介中所述，目前仅在具有非对称 CPU 拓扑的平台上支持 EAS。通过在构建调度域时查找 SD_ASYM_CPUCAPACITY_FULL 标志的存在，在运行时检查此要求。
请注意，EAS 与 SMP 并非根本不兼容，但尚未观察到在 SMP 平台上的显着节省。如果另有证明，此限制可能会在未来进行修改。
6.2 – 能源模型存在
EAS 使用平台的 EM 来估计调度决策对能量的影响。因此，您的平台必须向 EM 框架提供电力成本表才能启动 EAS。
6.3 – 能量模型复杂度
任务唤醒路径对延迟非常敏感。当平台的 EM 太复杂（CPU 太多、性能域太多、性能状态太多……）时，在唤醒路径中使用它的成本可能会令人望而却步。能量感知唤醒算法的复杂度为：
C = Nd * (Nc + Ns)
Nd 性能域的数量； Nc CPU 的数量；和 Ns 是 OPP 的总数（例如：对于两个具有 4 个 OPP 的性能域，Ns = 8）。
在构建调度域时，在根域级别执行复杂性检查。如果 EAS 的 C 恰好高于完全任意的 EM_MAX_COMPLEXITY 阈值（撰写本文时为 2048），则 EAS 将不会在根域上启动。
如果想使用 EAS 但平台的能量模型的复杂性太高而无法与单个根域一起使用，那么只有两种可能的选择：
使用独占的 cpuset 将您的系统拆分为单独的、较小的根域，并在每个域上本地启用 EAS。此选项的优点是开箱即用，但缺点是阻止根域之间的负载平衡，这可能导致系统整体不平衡;
提交补丁以降低 EAS 唤醒算法的复杂性，从而使其能够在合理的时间内处理更大的 EM。
6.4 – Schedutil 调控器
EAS 试图预测 CPU 在不久的将来将在哪个 OPP 上运行，以估计它们的能耗。为此，假设 CPU 的 OPP 遵循其利用率。
尽管在实践中很难为这个假设的准确性提供硬性保证（例如，因为硬件可能不会执行它被告知要做的事情），schedutil 与其他 CPUFreq 调控器相比，至少
requests
频率是使用利用率计算的信号。因此，与 EAS 一起使用的唯一合理的调控器是 schedutil，因为它是唯一一种在频率请求和能量预测之间提供一定程度一致性的调控器。不支持将 EAS 与 schedutil 以外的任何其他调控器一起使用。
6.5 尺度不变的利用率信息
为了对 CPU 和所有性能状态进行准确预测，EAS 需要频率不变和 CPU 不变的 PELT 信号。这些可以使用架构定义的 arch_scale{cpu,freq}_capacity() 回调获得。
不支持在未实现这两个回调的平台上使用 EAS。
6.6 超线程（SMT）
当前形式的 EAS 无法识别 SMT，并且无法利用超线程硬件来节省能源。 EAS 将超线程视为独立的 CPU，这实际上会对性能和能源产生反作用。不支持 SMT 上的 EAS。