EAS调度器缘起
Linux内核的一直都使用完全公平调度器CFS(Completely Fair Scheduler)作为默认调度器，但是在使用中发现CFS如下几个问题。
1. CFS主要是为了服务器性能优先场景而设计的，主要目标是最大限度地提高系统的吞吐量，CFS调度的目标是所有任务都平均分配到系统所有可用的CPU上。
2. CFS主要针对SMP系统，对于非SMP系统支持不足，比如说arm.big.little架构以及intel PE核架构。
3. 没有充分利用各个核的功耗，性能，频率差异来达到性能和功耗的最优平衡。
CFS调度器局限性分析
CFS使用PELT(per entity load tracking)跟踪任务负载，PELT负载统计公式如下
L = L0 + L1 * y + L2 * y2 + L3 * y3 + ... + Ln * yn y(32) = 0.5, y = 0.97857206
PELT在计算进程负载时，更适合的是CPU高吞吐量场景。对于交互进程，或者一个低cpu负载的进程，突然100%持续运行时，PTLT大概需要74ms才能达到最大负载的80%,需要大约139ms才能达到最大负载的95%。
PELT使用32ms的衰减实际，大约213ms才能把之前的负载忘记。
一个网络进程睡眠了500ms，然后突然突然发送或者接收大量网络数据包，PTLT并不能马上识别出它是一个重活。
对于睡眠或者阻塞的进程，PELT还会继续计算其衰减负载，但是这些继续贡献的负载对于下一次唤醒其实没有什么用处，因此会拖延降低CPU频率的速度，从而增加CPU功耗。
所以说，CFS这不适合手机或者消费电子，对功耗敏感的设备中。
EAS如何运作
能量模型
EAS引入了能量模型概念，EAS试图统一内核的三个不同核心部分，它们之前都相互独立，能量模型有助于统一它们，皆可能节省功耗提高性能。
1. Linux调度程序（CFS）
2. Linux cpuidle
3. Linux cpufreq
EAS调度程序统一3个模块个，因为将它们一起计算可以使它们尽可能高效。
CPUIdle尝试决定CPU何时进入空闲模式。
CPUFreq尝试决定何时加速或降低CPU。
不仅如此，EAS还将进程/程序/应用分为四个cgroup，即 top-app, system-background, foreground, and background,
将要处理的任务放入其中一个类别中，然后为该类别提供CPU power，并将工作委派给不同的CPU核心。
top-app是完成的最高优先级，其次是forground，background和system-background gorup。
backgound group与system-background group具有相同的优先级，但system-background group通常也可以访问更多的核心。
实际上，Energy Aware Scheduling正在将Linux内核的核心部分整合到一个进程中。
量化计算能力
EAS提出两个概念：
频率恒定引擎（Frequency Invariant Engine,FIE）：计算CPU负载时考虑CPU频率的变化。
CPU恒定引擎（CPU Invariant Engine,CIE）：考虑不同CPU架构的计算能力对负载的影响。
cpu_capacity_orig 和 cpu_capacity的区别：
就绪队列runqueue数据结构中新增两个成员
cpu_capacity_orig：指CPU在dts中定义的最高计算能力，这是量化值，系统中最强处理器的最高量化计算能力为1024。
cpu_capacity：当前cpu的CFS调度类量化计算能力，扣除DL和RT调度类之后剩余的CFS调度类的量化计算能力。
唤醒设备时，EAS将选择处于最浅空闲状态的核心，从而最大限度地减少唤醒设备所需的能量。这有助于降低使用设备所需的功率，因为如果不需要，它不会唤醒big cluster。
负载跟踪是EAS的一个非常重要的部分，EAS抛弃了PELT原始的负载跟踪算法，而是使用WALT（Window-Assisted Load Tracking）。
能效模型
em_perf_domain
< include/linux/energy_model.h >
struct em_perf_domain {
struct em_perf_state *table;
int nr_perf_states;
unsigned long flags;
unsigned long cpus[];
};
em_cap_state
em_cap_state {
unsigned long frequency; /* cpu的频率 */
unsigned long power; /* 改频率下的功耗 */
unsigned long cost; /* 能效系数 */
}
能效系数的计算
cost = power * (max_freq / freq)
WALT的原理
WALT(Windows-Assist Load Tracing)由Qcom研发，主要用于移动设备对性能功耗要求比较高的场景，
应用程序与用户交互时需要尽快响应，要能及时反应负载的增加和减少以驱动频点及时的变化。
当前的PELT负载跟踪算法更主要的是体现负载的连续性，对于突变性质的负载的反应不是很友好，负载上升慢，下降也慢。
WALT的核心算法思想
将一小段时间内的CPU loading情况计算出对应的结果，作为一个window；然后再统计多个类似的window。
通过计算，得出task demand，最后将结果运用于CPU 频率调节，负载均衡（task迁移）。
归一化负载统计具体过程
辅助计算项 window 的划分方法是将系统自启动开始以一定时间作为一个周期，分别统计不同周期内 Task 的 Loading 情况，并将其更新到Runqueue中；
目前 Kernel 中默认一个 window 的大小是20ms，统计 5 个window内的Loading情况。
对于一个Task和window，可能存在如下几种情况：
说明：
mark_start（Task开始）
window_start（当前window开始）
wallclock（当前系统时间）
三种情况计算方法：
1. Task在这个window内启动，且做统计时仍在这个window内，即Task在一个window内；
2. Task在前一个window内启动，做统计时在当前window内，即Task跨过两个window；
3. Task在前边某一个window内启动，做统计时在当前window内，即Task跨过多个完整window；
统计原理：
是以window作为辅助项来跟踪cpu load，用来表现cpu当前的loading情况。
每个窗口间隔20 ms，窗口记录项window_start这个值是每个负载队列一个
每个task 都记录本task的mark_start，然后根据window_start与wallclock的值进行计算
关键计算公式
new_window_start的计算
| new_window_start += ((wallclock - window_start) / window_size) * window_size |
window_start：本次统计时，窗口的计算时间
wallclock：wallclock是系统时间，从开机到现在的clock时间，单位为ns
window_size： 窗口大小20ms
scaled_util 计算公式
| scaled_util = (delta / window_size) * (curr_freq / max_freq) * cpu_capacity_max |
scaled_util：需要的cpu资源
delta：task 的cpu running时间
window_size：窗口大小 20 ms
curr_freq：当前cpu频率
max_freq：最大cpu频率
cpu_capacity_max：系统cpu最大量化值，最大1024
WALT触发入口
WALT结果用途
负载均衡
通过WALT获取该task的demand，然后计算每个cpu剩余算力，依据cpu在不同算力下的功耗情况，就可以确定task调度到哪个cpu是最低功耗，最终实现了功耗最低需求。
CPU freq调节
当cpu被增加task数量，cpu freq模块合理提升cpu频率，提高系统性能。
当cpu task数量减少，cpu freq模块降低cpu频率，降低系统功耗。
选择哪个CPU唤醒进程p
1. 一个系统中cpu的最高计算能力被量化成1024，小何CPU的最高计算能力也要量化，如512.
2. 要判断一个就绪队列的当前实际计算能力有多少，采用实际算力，读取cfs_rq->avg.util_avg可得到CFS就绪队列的实际算力。
3. 要计算一个进程p的实际算力，我们采用p->se.avg.util_avg。
4. 需要在小核性能域以及大河性能域里面对每个cpu进行计算。假设把进程p添加到该cpu里，是否能够容下？不能超过处理器额定算力的80%。
5. 要看大、小和这两个性能域里面，哪个cpu最适合安防，也就是说，容纳了进程p之后，它的剩余的计算鞥能力最多的为候选者。如小何CPU1和大核CPU3位候选者。
6. 比较进程运行在CPU1或者CPU3上最省电，经过发现最终迁移到CPU1上最省电，就选择CPU1。
