CPU负载均衡之EAS


前言

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

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

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

即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.

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

1.1 版本支持：

  1. linux 5.0以后添加了对EAS的支持，5.4完整功能支持，Contains full product EAS based on linux-5.4
  2. 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. 为什么需要

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

2.1 负载调节历代方案演变

演变过程中的几个方案：
YANBIAN

接下来具体来看：

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

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

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

HMP

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

从这里来看，该机制是基于可以独立控制大小core的电压值：
在这里插入图片描述
图片来自于linaro介绍EAS的资料：https://www.linaro.org/blog/energy-aware-scheduling-eas-progress-update/

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

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

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

2.2 设计思路

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

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

2.2.1 task分类

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

  1. top-app：最高优先级
  2. foreground：
  3. system-background：与4具有相同优先级，可以访问更多的core
  4. background：
    根据应用场景的不同，决定使用的核、频率（本质上与调度策略是一回事，这里添加一个功耗的输入条件）；
    在这里插入图片描述
1
2
3
4
5
//在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的机制，负载跟踪策略更加细化

  1. PELT（per-entry load tracing）：
    1. 统计CPU的负载，将负载的计算从RQ细化到了entity；
    2. 通过对过去负载的计算来决定后续的分配情况；
    3. 计算为1ms作为一个时间段，根据其运行的物理时间以及过去的load值来计算当前值；
    4. 则主要用来表达趋势
  2. WALT（window-assisted load tracing）：更具有突发性，峰值很高
    1. 参考网站：https://lwn.net/Articles/704903/
2.2.2.1 策略中存在的缺陷
  1. 采样周期长，导致反应慢
    在这里插入图片描述
  2. 平均负载过低导致整体负载忽高忽低，不平滑
    在这里插入图片描述
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