EAS之WALT算法介绍
EAS调度器缘起
Linux内核的一直都使用完全公平调度器CFS(Completely Fair Scheduler)作为默认调度器,但是在使用中发现CFS如下几个问题。
-
CFS主要是为了服务器性能优先场景而设计的,主要目标是最大限度地提高系统的吞吐量,CFS调度的目标是所有任务都平均分配到系统所有可用的CPU上。
-
CFS主要针对SMP系统,对于非SMP系统支持不足,比如说arm.big.little架构以及intel PE核架构。
-
没有充分利用各个核的功耗,性能,频率差异来达到性能和功耗的最优平衡。
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试图统一内核的三个不同核心部分,它们之前都相互独立,能量模型有助于统一它们,皆可能节省功耗提高性能。
-
Linux调度程序(CFS)
-
Linux cpuidle
-
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内核的核心部分整合到一个进程中。
量化计算能力
频率恒定引擎(Frequency Invariant Engine,FIE):计算CPU负载时考虑CPU频率的变化。
CPU恒定引擎(CPU Invariant Engine,CIE):考虑不同CPU架构的计算能力对负载的影响。
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
-
一个系统中cpu的最高计算能力被量化成1024,小核CPU的最高计算能力也要量化,如512.
-
要判断一个就绪队列的当前实际计算能力有多少,采用实际算力,读取cfs_rq->avg.util_avg可得到CFS就绪队列的实际算力。
-
要计算一个进程p的实际算力,我们采用p->se.avg.util_avg。
-
需要在小核性能域以及大河性能域里面对每个cpu进行计算。假设把进程p添加到该cpu里,是否能够容下?不能超过处理器额定算力的80%。
-
要看大、小和这两个性能域里面,哪个cpu最适合安放,也就是说,容纳了进程p之后,它的剩余的计算能力最多的为候选者。如小何CPU1和大核CPU3位候选者。
-
比较进程运行在CPU1或者CPU3上最省电,经过发现最终迁移到CPU1上最省电,就选择CPU1。