linux进程、线程及调度算法（三）

调度策略值得是大家都在ready时，并且CPU已经被调度时，决定谁来运行，谁来被调度。

两者之间有一定矛盾。

响应的优化，意味着高优先级会抢占优先级，会花时间在上下文切换，会影响吞吐。

上下文切换的时间是很短的，几微妙就能搞定。上下文切换本身对吞吐并多大影响， 重要的是，切换后引起的cpu 的 cache miss.

每次切换APP, 数据都要重新load一次。

Linux 会尽可能的在响应与吞吐之间寻找平衡。比如在编译linux的时候，会让你选择 kernal features ->Preemption model.

抢占模型会影响linux的调度算法。

所以 ARM 的架构都是big+LITTLE， 一个很猛CPU+ 多个 性能较差的 CPU, 那么可以把I/O型任务的调度 放在 LITTLE CPU上。需要计算的放在big上。

早期2.6 内核将优先级划分了 0-139 bit的优先级。数值越低，优先级越高。0-99优先级 都是 RT（即时响应）的 ，100-139都是非RT的，即normal。

调度的时候 看哪个bitmap 中的 优先级上有任务ready。可能多个任务哦。

在普通优先级线程调度中，高优先级并不代表对低优先级的绝对优势。会在不同优先级进行轮转。

100 就是比101高，101也会比102高，但100 不会堵着101。

众屌丝进程在轮转时，优先级高的：

初始设置nice值为0，linux 会探测 你是喜欢睡眠，还是干活。越喜欢睡，linux 越奖励你，优先级上升（nice值减少）。越喜欢干活，优先级下降（nice值增加）。所以一个进程在linux中，干着干着 优先级越低，睡着睡着 优先级越高。

后期linux补丁中

红黑树，数据结构， 左边节点小于右边节点

同时兼顾了 CPU/IO 和 nice。

数值代表着 进程运行到目前为止的virtual runtime 时间。

（pyhsical runtime） / weight * 1024(系数)。

优先调度 节点值（vruntime）最小的线程。权重weight 其实有nice 来控制。

一个线程一旦被调度到，则物理运行时间增加，vruntime增加，往左边走。

weight的增加，也导致vruntime减小，往右边走。

总之 CFS让线程 从左滚到右，从右滚到左。即照顾了I/O(喜欢睡，分子小) 也 照顾了 nice值低（分母高）.所以 由喜欢睡，nice值又低的线程，最容易被调度到。

自动调整，无需向nice一样做出奖励惩罚动作，个人理解权重其实相当于nice

但是 此时 来一个 0-99的线程，进行RT调度，都可以瞬间秒杀你！因为人家不是普通的，是RT的!

一个多线程的进程中，每个线程的调度的策略 如 fifo rr normal, 都可以不同。每一个的优先级都可以不一样。

实验举例, 创建2个线程，同时开2个：

运行2次，创建两个进程

sudo renice -n -5(nice -5级别) -g(global)， 会明显看到 一个进程的CPU占用率是另一个的 3倍。

为什么cpu都已经达到200%，为什么系统不觉得卡呢？因为，我们的线程在未设置优先级时，是normal调度模式，且是 CPU消耗型 调度级别其实不高。

利用chrt工具，可以将进程 调整为 50 从normal的调度策略 升为RT （fifo）级别的调度策略，会出现：

chrt , nice renice 的调度策略 都是以线程为单位的，以上 设置的将进程下的所有线程进行设置nice值

线程是调度单位，进程不是，进程是资源封装单位！

两个同样死循环的normal优先级线程，其中一个nice值降低，该线程的CPU 利用率就会比另一个CPU的利用率高。

在前文中，我们分析了内核中进程和线程的统一结构体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核心函数

进程调度的算法有很多，简单来说就是每个进程都有一个自己的时间片，时间到了，就会被挂起，然后系统挑选下一个合适的进程来执行。至于谁合适，那就要看算法了，优先级，是不是饥饿，I/O型还是运算型，都要考虑的。

调度算法比较复杂庞大，不是这里说的清楚的。

进程切换的过程大概就是保存当前上下文，也就是各种寄存器的状态，包括指令寄存器。然后把下一个进程的上下文加载上来。

有了线程机制之后，进程管理主要管理线程之间的数据共享，管理进程地址空间，进程的交换空间。因为这些资源是属于进程的，线程之间是共享的。

​现代 *** 作系统调度基本是围绕线程进行的，进程更多的是起到资源管理分配的作用。

---