EAS-概述

What is EAS ?

Energy Aware Scheduler（EAS）是Android手机默认的Scheduler。通过为每个任务选择正确的CPU，达到性能和功耗相平衡。它可以在big.LITTLE和DynamIQArm平台上实现节能调度决策。

EAS是Linux任务计划调度的扩展，可延长移动设备的电池寿命。它使用CPU能耗模型（EM）来优化任务在big.LITTLE和/或DynamIQ平台上最节能的CPU上的调度，同时满足计算要求。EM向调度程序提供CPU能耗/频率视图。然后，使用EM，EAS可以预测在一个或多个特定CPU上执行任务对能量的影响，并做出使能耗最小化的决策。

EAS的关键设计点在于它与DVFS子系统CPUFreq的紧密绑定，该子系统负责驱动CPU的频率。schedutilCPUFreq调控器使用调度程序的负载跟踪指标来确定CPU的频率变化。EAS算法也使用相同的指标来协调频率请求和任务放置决策。这种协调水平与EM相结合，使EAS可以估计任务迁移如何影响系统的能耗，并在决策过程中将其考虑在内。从本质上讲，EAS使Linux任务计划程序能够利用小型CPU的能源效率来提高移动设备的电池寿命，而不会损害性能。

一个例子

让我们考虑一个具有2个独立性能域的平台。每个由两个CPU组成。CPU0和CPU1是小core，功耗低但是性能差。CPU2和CPU3是大core，功耗高，但性能好。

假设任务P的util_avg = 200，prev_cpu = 0。那么EAS把P 放到哪个CPU 上呢？

该图显示了CPU的当前利用率情况，CPU0-3的util_avg分别为400、100、600和500。每个性能域都有三个操作性能点（OPP）。与每个OPP相关的CPU容量和电源成本列在能源模型表。P的util_avg如图所示“ PP”。

find_energy_efficient_cpu（）将首先查找具有以下内容的CPU：

• 两个性能域中的最有能力处理该任务 的CPU。在这个例子中是CPU1和 CPU3。CPU1 util_avg 是100 小于 CPU0 400.CPU3 util_avg 是500 小于CPU2 600。
• 把P放在其中任何一个CPU上， 并计算其消耗的power。
• 将P留在CPU0上。计算其power。
•  EAS 将选择power 最低的CPU 来放置P

Power=(util_avg/cap)xpwr

根据这些计算，case 1具有最低的power消耗。从能源效率的角度来看CPU 1是最佳的选择。大core通常比小core耗电更多，性能更好。因此一般来说，大core 仅仅用来对小core 不能满足性能的时候，才把任务放在大core 上运行。

然而生活常识告诉我们，凡事皆有意外。

EAS 也是如此，把一些任务放到大core的低频段，所消耗的power并不是一定比把任务放在小core 上（跑在高频段）多。传统的调度器不能解决此问题，而EAS 能很好的解决能效比的问题。

Over-utilization

基本上，EAS能cover 大多数轻/中CPU使用率的用例。

然而当执行长时间的CPU-bound任务时，如果完全采用EAS，那么EAS 可能为了节省功耗而伤害性能。为了避免EAS损害性能，一旦CPU的利用率超过80％，EAS将CPU标记为“over-utilized”。只要在调度根域中没有过度使用CPU（80%），负载平衡将被禁用。EAS根据能效比来选择任务的放置。即EAS 将把任务放置在最低能耗比的CPU 上。而一旦CPU 为over-utilized，将不再使用EAS 来放置任务到CPU ，因此使用EAS就意味，

• 所有CPU上都有一些空闲时间， 因此EAS能准确预测各种任务的“大小”
• 所有任务都能在CPU 上很好的执行， 完成自己的工作。
• 由于CPU 还有余量，因此所有任务都 必须能正常的处于阻塞/休眠状态，定期进行唤醒时保持负载平衡

一旦一个CPU超过临界点80％，或至少上面的三个假设变得不成立，在这种情况下，“ overutilized”标志为整个调度根域。此时，禁用EAS，负载均衡器启用。这样，调度程序便退回到了基于负载的算法上，来为唤醒的任务选择CPU和负载平衡。

由于over-utilized的概念主要取决于检测系统中是否有一些空闲

时间，因此CPU被其他“更高（而不是CFS）调度类（以及IRQ）的使用必须考虑在内。

EAS 架构