深入解析Linux进程调度器-CPU负载

2022-12-14 15:04 作者:补给站Linux内核 0人读过 | 我要投稿

说明：

Kernel版本：4.14
ARM64处理器，Contex-A53，双核
使用工具：Source Insight 3.5， Visio

1. 概述

CPU负载（cpu load）指的是某个时间点进程对系统产生的压力。来张图来类比下（参考Understanding Linux CPU Load）

CPU的运行能力，就如大桥的通行能力，分别有满负荷，非满负荷，超负荷等状态，这几种状态对应不同的cpu load值；
单CPU满负荷运行时cpu_load为1，当多个CPU或多核时，相当于大桥有多个车道，满负荷运行时cpu_load值为CPU数或多核数；
CPU负载的计算（以单CPU为例），假设一分钟内执行10个任务代表满负荷，当一分钟给出30个任务时，CPU只能处理10个，剩余20个不能处理，cpu_load=3；

在实际系统中查看：

cat /proc/cpuinfo：查看CPU信息；
cat /proc/loadavg：查看cpu最近1/5/15分钟的平均负载：

计算CPU负载，可以让调度器更好的进行负载均衡处理，以便提高系统的运行效率。此外，内核中的其他子系统也可以参考这些CPU负载值来进行相应的调整，比如DVFS等。

目前内核中，有以下几种方式来跟踪CPU负载：

全局CPU平均负载；
运行队列CPU负载；
PELT（per entity load tracking）;

这也是本文需要探讨的内容，开始吧。

2. 全局CPU平均负载

2.1 基础概念

先来明确两个与CPU负载计算相关的概念：

active task（活动任务）：只有知道活动任务数量，才能计算CPU负载，而活动任务包括了TASK_RUNNING和TASK_UNINTERRUPTIBLE两类任务。包含TASK_UNINTERRUPTIBLE任务的原因是，这类任务经常是在等待I/O请求，将其包含在内也合理；
NO_HZ：我们都知道Linux内核每隔固定时间发出timer interrupt，而HZ是用来定义1秒中的timer interrupts次数，HZ的倒数是tick，是系统的节拍器，每个tick会处理包括调度器、时间管理、定时器等事务。周期性的时钟中断带来的问题是，不管CPU空闲或繁忙都会触发，会带来额外的系统损耗，因此引入了NO_HZ模式，可以在CPU空闲时将周期性时钟关掉。在NO_HZ期间，活动任务数量的改变也需要考虑，而它的计算不如周期性时钟模式下直观。

【文章福利】小编推荐自己的Linux内核技术交流群:【749907784】整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！！！（含视频教程、电子书、实战项目及代码)

2.2 流程

Linux内核中定义了三个全局变量值avenrun[3]，用于存放最近1/5/15分钟的平均CPU负载。

看一下计算流程：

计算活动任务数，这个包括两部分：1）周期性调度中新增加的活动任务；2）在NO_HZ期间增加的活动任务数；
根据活动任务数值，再结合全局变量值avenrun[]中的old value，来计算新的CPU负载值，并最终替换掉avenrun[]中的值；
系统默认每隔5秒钟会计算一次负载，如果由于NO_HZ空闲而错过了下一个CPU负载的计算周期，则需要再次进行更新。比如NO_HZ空闲20秒而无法更新CPU负载，前5秒负载已经更新，需要计算剩余的3个计算周期的负载来继续更新；

2.3 计算方法

Linux内核中，采用11位精度的定点化计算，CPU负载1.0由整数2048表示，宏定义如下：

计算公式如下：

load值为旧的CPU负载值avenrun[]，整个计算完成后得到新的负载值，再更新avenrun[]；
EXP_1/EXP_5/EXP_15，分别代表最近1/5/15分钟的定点化值的指数因子；
active值，根据读取calc_load_tasks的值来判断，大于0则乘以FIXED_1(2048)传入；
根据active和load值的大小关系来决定是否需要加1，类似于四舍五入的机制；

关键代码如下：

NO_HZ模式下活动任务数量更改的计算由于NO_HZ空闲效应而更改的CPU活动任务数量，存放在全局变量calc_load_nohz[2]中，并且每5秒计算周期交替更换一次存储位置(calc_load_read_idx/calc_load_write_idx)，其他程序可以去读取最近5秒内的活动任务变化的增量值。

计算示例假设在某个CPU上，开始计算时load=0.5，根据calc_load_tasks值获取不同的active，中间进入NO_HZ模式空闲了20秒，整个计算的值如下图：

3. 运行队列CPU负载

Linux系统会计算每个tick的平均CPU负载，并将其存储在运行队列中rq->cpu_load[5]，用于负载均衡；

下图显示了计算运行队列的CPU负载的处理流程：

最终通过cpu_load_update来计算，逻辑如下：

其中传入的this_load值，为运行队列现有的平均负载值。

上图中的衰减因子，是在NO_HZ模式下去进行计算的。在没有使用tick时，从预先计算的表中计算负载值。Linux内核中定义了两个全局变量：

衰减因子的计算主要是在delay_load_missed()函数中完成，该函数会返回load * 衰减因子的值，作为上图中的old_load。计算方式如下：

4. PELT

PELT, Per-entity load tracking。在Linux引入PELT之前，CFS调度器在计算CPU负载时，通过跟踪每个运行队列上的负载来计算；在引入PELT之后，通过跟踪每个调度实体的负载贡献来计算。（其中，调度实体：指task或task_group）

4.1 PELT计算方法

总体的计算思路：将调度实体的可运行状态时间（正在运行+等待CPU调度运行），按1024us划分成不同的周期，计算每个周期内该调度实体对系统负载的贡献，最后完成累加。其中，每个计算周期，随着时间的推移，需要乘以衰减因子y进行一次衰减操作。

先来看一下每个调度实体的负载贡献计算公式：

当前时间点的负载贡献 = 当前时间点负载 + 上个周期负载贡献 * 衰减因子；
假设一个调度实体被调度运行，运行时间段可以分成三个段d1/d2/d3，这三个段是被1024us的计算周期分割而成，period_contrib是调度实体last_update_time时在计算周期间的贡献值，；
总体的贡献值，也是根据d1/d2/d3来分段计算，最终相加即可；
y为衰减因子，每隔1024us就乘以y来衰减一次；

计算的调用流程如下图：

函数主要是计算时间差，再分成d1/d2/d3来分段计算处理，最终更新相应的字段；
decay_load函数要计算val * y^n，内核提供了一张表来避免浮点运算，值存储在runnable_avg_yN_inv数组中；

Linux中使用struct sched_avg来记录调度实体和CFS运行队列的负载信息，因此struct sched_entity和struct cfs_rq结构体中，都包含了struct sched_avg，字段介绍如下：

4.2 PELT计算调用

PELT计算的发生时机如下图所示：

调度实体的相关操作，包括入列出列操作，都会进行负载贡献的计算；

原文作者：LoyenWang

标签：