一文读懂Linux任务间调度原理和整个执行过程

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一文读懂Linux任务间调度原理和整个执行过程相关的知识,希望对你有一定的参考价值。

参考技术A

在前文中,我们分析了内核中进程和线程的统一结构体task_struct,并分析进程、线程的创建和派生的过程。在本文中,我们会对任务间调度进行详细剖析,了解其原理和整个执行过程。由此,进程、线程部分的大体框架就算是介绍完了。本节主要分为三个部分:Linux内核中常见的调度策略,调度的基本结构体以及调度发生的整个流程。下面将详细展开说明。

Linux 作为一个多任务操作系统,将每个 CPU 的时间划分为很短的时间片,再通过调度器轮流分配给各个任务使用,因此造成多任务同时运行的错觉。为了维护 CPU 时间,Linux 通过事先定义的节拍率(内核中表示为 HZ),触发时间中断,并使用全局变量 Jiffies 记录了开机以来的节拍数。每发生一次时间中断,Jiffies 的值就加 1。节拍率 HZ 是内核的可配选项,可以设置为 100、250、1000 等。不同的系统可能设置不同的数值,可以通过查询 /boot/config 内核选项来查看它的配置值。

Linux的调度策略主要分为实时任务和普通任务。实时任务需求尽快返回结果,而普通任务则没有较高的要求。在前文中我们提到了task_struct中调度策略相应的变量为policy,调度优先级有prio, static_prio, normal_prio, rt_priority几个。优先级其实就是一个数值,对于实时进程来说,优先级的范围是 0 99;对于普通进程,优先级的范围是 100 139。数值越小,优先级越高。

实时调度策略主要包括以下几种

普通调度策略主要包括以下几种:

首先,我们需要一个结构体去执行调度策略,即sched_class。该类有几种实现方式

普通任务调度实体源码如下,这里面包含了 vruntime 和权重 load_weight,以及对于运行时间的统计。

在调度时,多个任务调度实体会首先区分是实时任务还是普通任务,然后通过以时间为顺序的红黑树结构组合起来,vruntime 最小的在树的左侧,vruntime最多的在树的右侧。以CFS策略为例,则会选择红黑树最左边的叶子节点作为下一个将获得 CPU 的任务。而这颗红黑树,我们称之为运行时队列(run queue),即struct rq。

其中包含结构体cfs_rq,其定义如下,主要是CFS调度相关的结构体,主要有权值相关变量、vruntime相关变量以及红黑树指针,其中结构体rb_root_cached即为红黑树的节点

对结构体dl_rq有类似的定义,运行队列由红黑树结构体构成,并按照deadline策略进行管理

对于实施队列相应的rt_rq则有所不同,并没有用红黑树实现。

下面再看看调度类sched_class,该类以函数指针的形式定义了诸多队列操作,如

调度类分为下面几种:

队列操作中函数指针指向不同策略队列的实际执行函数函数,在linux/kernel/sched/目录下,fair.c、idle.c、rt.c等文件对不同类型的策略实现了不同的函数,如fair.c中定义了

以选择下一个任务为例,CFS对应的是pick_next_task_fair,而rt_rq对应的则是pick_next_task_rt,等等。

由此,我们来总结一下:

有了上述的基本策略和基本调度结构体,我们可以形成大致的骨架,下面就是需要核心的调度流程将其拼凑成一个整体,实现调度系统。调度分为两种,主动调度和抢占式调度。

说到调用,逃不过核心函数schedule()。其中sched_submit_work()函数完成当前任务的收尾工作,以避免出现如死锁或者IO中断等情况。之后首先禁止抢占式调度的发生,然后调用__schedule()函数完成调度,之后重新打开抢占式调度,如果需要重新调度则会一直重复该过程,否则结束函数。

而__schedule()函数则是实际的核心调度函数,该函数主要操作包括选取下一进程和进行上下文切换,而上下文切换又包括用户态空间切换和内核态的切换。具体的解释可以参照英文源码注释以及中文对各个步骤的注释。

其中核心函数是获取下一个任务的pick_next_task()以及上下文切换的context_switch(),下面详细展开剖析。首先看看pick_next_task(),该函数会根据调度策略分类,调用该类对应的调度函数选择下一个任务实体。根据前文分析我们知道,最终是在不同的红黑树上选择最左节点作为下一个任务实体并返回。

下面来看看上下文切换。上下文切换主要干两件事情,一是切换任务空间,也即虚拟内存;二是切换寄存器和 CPU 上下文。关于任务空间的切换放在内存部分的文章中详细介绍,这里先按下不表,通过任务空间切换实际完成了用户态的上下文切换工作。下面我们重点看一下内核态切换,即寄存器和CPU上下文的切换。

switch_to()就是寄存器和栈的切换,它调用到了 __switch_to_asm。这是一段汇编代码,主要用于栈的切换, 其中32位使用esp作为栈顶指针,64位使用rsp,其他部分代码一致。通过该段汇编代码我们完成了栈顶指针的切换,并调用__switch_to完成最终TSS的切换。注意switch_to中其实是有三个变量,分别是prev, next, last,而实际在使用时,我们会对last也赋值为prev。这里的设计意图需要结合一个例子来说明。假设有ABC三个任务,从A调度到B,B到C,最后C回到A,我们假设仅保存prev和next,则流程如下

最终调用__switch_to()函数。该函数中涉及到一个结构体TSS(Task State Segment),该结构体存放了所有的寄存器。另外还有一个特殊的寄存器TR(Task Register)会指向TSS,我们通过更改TR的值,会触发硬件保存CPU所有寄存器在当前TSS,并从新的TSS读取寄存器的值加载入CPU,从而完成一次硬中断带来的上下文切换工作。系统初始化的时候,会调用 cpu_init()给每一个 CPU 关联一个 TSS,然后将 TR 指向这个 TSS,然后在操作系统的运行过程中,TR 就不切换了,永远指向这个 TSS。当修改TR的值得时候,则为任务调度。

更多Linux内核视频教程文本资料免费领取后台私信【 内核大礼包 】自行获取。

在完成了switch_to()的内核态切换后,还有一个重要的函数finish_task_switch()负责善后清理工作。在前面介绍switch_to三个参数的时候我们已经说明了使用last的重要性。而这里为何让prev和last均赋值为prev,是因为prev在后面没有需要用到,所以节省了一个指针空间来存储last。

至此,我们完成了内核态的切换工作,也完成了整个主动调度的过程。

抢占式调度通常发生在两种情况下。一种是某任务执行时间过长,另一种是当某任务被唤醒的时候。首先看看任务执行时间过长的情况。

该情况需要衡量一个任务的执行时间长短,执行时间过长则发起抢占。在计算机里面有一个时钟,会过一段时间触发一次时钟中断,通知操作系统时间又过去一个时钟周期,通过这种方式可以查看是否是需要抢占的时间点。

时钟中断处理函数会调用scheduler_tick()。该函数首先取出当前CPU,并由此获取对应的运行队列rq和当前任务curr。接着调用该任务的调度类sched_class对应的task_tick()函数进行时间事件处理。

以普通任务队列为例,对应的调度类为fair_sched_class,对应的时钟处理函数为task_tick_fair(),该函数会获取当前的调度实体和运行队列,并调用entity_tick()函数更新时间。

在entity_tick()中,首先会调用update_curr()更新当前任务的vruntime,然后调用check_preempt_tick()检测现在是否可以发起抢占。

check_preempt_tick() 先是调用 sched_slice() 函数计算出一个调度周期中该任务运行的实际时间 ideal_runtime。sum_exec_runtime 指任务总共执行的实际时间,prev_sum_exec_runtime 指上次该进程被调度时已经占用的实际时间,所以 sum_exec_runtime - prev_sum_exec_runtime 就是这次调度占用实际时间。如果这个时间大于 ideal_runtime,则应该被抢占了。除了这个条件之外,还会通过 __pick_first_entity 取出红黑树中最小的进程。如果当前进程的 vruntime 大于红黑树中最小的进程的 vruntime,且差值大于 ideal_runtime,也应该被抢占了。

如果确认需要被抢占,则会调用resched_curr()函数,该函数会调用set_tsk_need_resched()标记该任务为_TIF_NEED_RESCHED,即该任务应该被抢占。

某些任务会因为中断而唤醒,如当 I/O 到来的时候,I/O进程往往会被唤醒。在这种时候,如果被唤醒的任务优先级高于 CPU 上的当前任务,就会触发抢占。try_to_wake_up() 调用 ttwu_queue() 将这个唤醒的任务添加到队列当中。ttwu_queue() 再调用 ttwu_do_activate() 激活这个任务。ttwu_do_activate() 调用 ttwu_do_wakeup()。这里面调用了 check_preempt_curr() 检查是否应该发生抢占。如果应该发生抢占,也不是直接踢走当前进程,而是将当前进程标记为应该被抢占。

由前面的分析,我们知道了不论是是当前任务执行时间过长还是新任务唤醒,我们均会对现在的任务标记位_TIF_NEED_RESCUED,下面分析实际抢占的发生。真正的抢占还需要一个特定的时机让正在运行中的进程有机会调用一下 __schedule()函数,发起真正的调度。

实际上会调用__schedule()函数共有以下几个时机

从系统调用返回用户态:以64位为例,系统调用的链路为do_syscall_64->syscall_return_slowpath->prepare_exit_to_usermode->exit_to_usermode_loop。在exit_to_usermode_loop中,会检测是否为_TIF_NEED_RESCHED,如果是则调用__schedule()

内核态启动:内核态的执行中,被抢占的时机一般发生在 preempt_enable() 中。在内核态的执行中,有的操作是不能被中断的,所以在进行这些操作之前,总是先调用 preempt_disable() 关闭抢占,当再次打开的时候,就是一次内核态代码被抢占的机会。preempt_enable() 会调用 preempt_count_dec_and_test(),判断 preempt_count 和 TIF_NEED_RESCHED 是否可以被抢占。如果可以,就调用 preempt_schedule->preempt_schedule_common->__schedule 进行调度。

   本文分析了任务调度的策略、结构体以及整个调度流程,其中关于内存上下文切换的部分尚未详细叙述,留待内存部分展开剖析。

1、调度相关结构体及函数实现

2、schedule核心函数

一文读懂:开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么?

一、什么是工作流?

在阐述什么是工作流之前,先说一下工作流和普通任务的区别,在于依赖视图。

普通任务本身他只会有自己的 dag 图,依赖视图是无边界的,不可控的,而工作流则是把整个工作流都展示出来,是有边界的,可控的,这是工作流的优势。下面为大家介绍工作流的相关功能:

01 工作流 — 功能介绍

● 虚拟节点

虚拟节点,它是不产生任何数据的空跑节点(即调度到该节点时,系统直接返回成功,不会真正执行、不会占用资源或阻塞下游节点运行),比如说任务并行执行,那么就会用到虚拟节点。

一文读懂:开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么?_数据

● 周期生成

指调度系统按照调度配置自动定时运行的任务。

一文读懂:开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么?_spark_02

● 补数据运行

当业务变更,可以使用补数据功能。如修改了某个任务的代码,可将本月的数据按照新的代码重新跑一遍,立即生成所需数据。

● 调度属性

工作流中的子任务依赖于父任务的周期调度属性,父任务修改后,子任务同步修改,以工作流的周期调度属性作为各个子节点的周期调度时间。 

一文读懂:开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么?_子任务_03

● 工作流所在目录

修改工作流目录同步修改工作流下的子任务目录。 

一文读懂:开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么?_数据_04

02 工作流 — 依赖成环

具体实现:

任务完成依赖的关系,key 为当前节点,value 为该节点的所有父节点 Map <long list> nodeMap。

一文读懂:开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么?_spark_05

遍历 nodeMap,以此遍历单集合中的每一个节点。每遍历一个新节点,就从头检查新节点之前的所有节点,用新节点和此节点之前所有节点依次做比较。如果发现新节点和之前的某个节点相同,则说明该节点被遍历过两次,链表有环。如果之前的所有节点中不存在与新节点相同的节点,就继续遍历下一个新节点,继续重复刚才的操作。

二、Taier 工作流周期实例运行

了解完工作流的功能介绍后,我们来为大家分享 Taier 工作流周期实例运行:

01 Taier— 周期实例生成

Taier 主节点在启动的时候,会开启一个定时器,定时器会不停的去判断当日的实例是否已经生成。如果没有生成,就会触发事件给 CycleJobBuilder 生成实例,再通过 JobDependency 封装实例之间的依赖关系。

● CycleJobBuilder

用于生成周期实例。扫描数据库任务表并且获取 zk 上所有的 Taier 节点,把封装后的实例分配到每一台 Taier 节点上。

● JobDependency

用于生成 job 之间的依赖关系。

一文读懂:开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么?_数据_06

02 Taier— 调度流程

在启动 Taier 服务时,会启动配置的所有调度器,并且开始扫描实例,并提交。

一文读懂:开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么?_子任务_07

03 Taier— 工作流任务状态修改逻辑

任务提交拦截器处理:

1、工作流下无子任务更新为完成状态

2、工作流下任务都是完成状态,任务提交队列可以移除

3、同时更新工作流 engine_job 状态,工作流只有四种状态,成功 / 失败 / 取消 / 提交中:

(1) 所有子任务状态为运行成功时,工作流状态更新为成功
(2) 工作流状态根据子任务的运行状态来确定,失败状态存在优先级:运行失败 > 提交失败 > 上游失败
a. 子任务存在运行失败时,工作流状态更新为运行失败
b. 子任务不存在运行失败时,存在提交失败,工作流状态更新为提交失败
c. 子任务不存在运行失败时,不存在提交失败,存在上游失败时,工作流状态更新为上游失败
(3) 子任务存在取消状态时,工作流状态更新为取消
(4) 若子任务中同时存在运行失败或取消状态,工作流状态更新为失败状态
(5) 其他工作流更新为运行中状态

三、Taier1.3 即将上线功能

新增功能

・ChunJun 的向导模式数据源增强 hive1、hive2、hive3、sparkThrift、oracle、mysql、postgresql、sqlserver 、es7

・flink on standalone、python.shell、spark jar 、pyspark 支持

・自定义任务类型 web 界面配置抽取

・windows 开发环境适配


以上是关于一文读懂Linux任务间调度原理和整个执行过程的主要内容,如果未能解决你的问题,请参考以下文章

任务调度框架 Quartz 一文读懂

任务调度框架 Quartz 一文读懂

一文搞懂Linux进程调度原理

一文读懂JDK源码:ThreadPoolExecutor

一文读懂:开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么?

Makefile入门(超详细一文读懂)