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。