CPU负载均衡之EAS

前言

记录一个问题点，三个action；

本文主要记录linux 负载均衡策略的发展：

EAS 概念说明
为什么需要，或者说之前的框架遇到了什么问题，所以才需要新的内容？
框架变化

即linux中对于TASK调度、负载跟踪和调节的处理；

1. EAS

EAS 即 Energy Aware Scheduling：
EAS is an enhancement to Linux power management, placing CPU power control directly under the Linux scheduler. When enabled, EAS uses the task load and a CPU Energy Model to select the most efficient CPU to run on, taking advantage of power and performance of Arm big.LITTLE and Arm DynamIQ-based systems.

linux电源管理的增强处理，根据linux调度器来控制CPU的power；
会根据task load和CPU energy model来选择合适的CPU（core以及频率），均衡性能和功耗；

1.1 版本支持：

linux 5.0以后添加了对EAS的支持，5.4完整功能支持，Contains full product EAS based on linux-5.4
For Android use, EAS is available as part of AOSP Common Kernel. AOSP Common Kernel contains a small number of additional Android-specific patches on top of the Linux kernel EAS.
1. Android中对应kernel版本3.18、4.4、4.9都是支持EAS的

2. 为什么需要

linux的调度策略：CFS 、SMP主要是为服务器设计，最大限度的将TASK均分给到各个CPU，以提高吞吐量，也就是说主要考虑的性能，而没有考虑功耗；
arm 支持大小核的异构方案，此前的版本中没有针对于此方案做优化；
本质上来说，早期版本主要考虑性能指标，而非功耗，随着arm的各种新技术的发展，各种移动设备需要在功耗和性能上达到一个平衡，所以就需要一种新的方案；

2.1 负载调节历代方案演变

演变过程中的几个方案：

接下来具体来看：

2.1.1 SMP：保证各个core task处于均衡状态

此时的task分配主要基于linux 2.6 中的调度策略的CFS，SMP是基于该调度策略平均的balance各个core的负载；

2.1.2 HMP：高通提出来的，用于动态调节big和little core，相对于SMP（CFS）对于big-little core有更好的适应

sd： sched_domain
sg： sched_group
简单理解就是将低优先级的任务放在little core上进行，重要任务放在big core上进行，按照规则分配，安全且高效；

从这里来看，该机制是基于可以独立控制大小core的电压值：

图片来自于linaro介绍EAS的资料：https://www.linaro.org/blog/energy-aware-scheduling-eas-progress-update/

每个工作域独立控制电压和频率；
则可以根据负载、task内容等分别控制各个域；

2.1.3 EAS：linux 针对优化，在所有核之间分配；

相对于HMP，添加功耗感知模块，可以动态调节负载情况，达到通过更少的消耗满足更顺滑的效果；

2.2 设计思路

将当前系统中调度、负载、调节等功能统合起来作为系统性能、功耗平衡的使用

根据当前TASK的类别和每个CPU的负载情况来分配到不同的CPU上；
根据负载情况配置CPU core和freq的DVFS、cpu hotplug机制，通过CPUFreq来管理；
1. CFS
2. CPUIdle：如下图示中说明cluster 0 为on，其中cpu0 有在做事情，CPU1 为ilde状态，则新创建的TASK会分配到CPU1上，cluster 1为 off

2.2.1 task分类

Task 分为四个cgroup（将task分类，根据类别不同使用不同的core和频率）：

top-app：最高优先级
foreground：
system-background：与4具有相同优先级，可以访问更多的core
background：
根据应用场景的不同，决定使用的核、频率（本质上与调度策略是一回事，这里添加一个功耗的输入条件）；

//在init.rc中会对不同的group设置为不同的cpu
write /dev/cpuset/top-app/cpus 0-3
write /dev/cpuset/foreground/cpus 0-2
write /dev/cpuset/background/cpus 0
write /dev/cpuset/system-background/cpus 0-2

2.2.2 负载跟踪

在linux 3.8之后基于CFS的机制，负载跟踪策略更加细化

PELT（per-entry load tracing）：
1. 统计CPU的负载，将负载的计算从RQ细化到了entity；
2. 通过对过去负载的计算来决定后续的分配情况；
3. 计算为1ms作为一个时间段，根据其运行的物理时间以及过去的load值来计算当前值；
4. 则主要用来表达趋势
WALT（window-assisted load tracing）：更具有突发性，峰值很高
1. 参考网站：https://lwn.net/Articles/704903/

2.2.2.1 策略中存在的缺陷

采样周期长，导致反应慢
平均负载过低导致整体负载忽高忽低，不平滑

2.2.2.2 对比

3. 目前对于框架的理解（后续研究code时随时更新）

4. 参考资料：

https://www.linaro.org/blog/energy-aware-scheduling-eas-progress-update/
https://lwn.net/Articles/704903/
https://developer.arm.com/tools-and-software/open-source-software/linux-kernel/energy-aware-scheduling