Linux进程的调度

Posted 2023-04-13

参考技术A 上回书说到 Linux进程的由来 和 Linux进程的创建 ，其实在同一时刻只能支持有限个进程或线程同时运行(这取决于CPU核数量，基本上一个进程对应一个CPU)，在一个运行的操作系统上可能运行着很多进程，如果运行的进程占据CPU的时间很长，就有可能导致其他进程饿死。为了解决这种问题，操作系统引入了 进程调度器 来进行进程的切换，轮流让各个进程使用CPU资源。

1）rq： 进程的运行队列( runqueue)， 每个CPU对应一个 ，包含自旋锁(spinlock)、进程数量、用于公平调度的CFS信息结构、当前运行的进程描述符等。实际的进程队列用红黑树来维护(通过CFS信息结构来访问)。

2）cfs_rq： cfs调度的进程运行队列信息 ，包含红黑树的根结点、正在运行的进程指针、用于负载均衡的叶子队列等。

3）sched_entity： 把需要调度的东西抽象成调度实体 ，调度实体可以是进程、进程组、用户等。这里包含负载权重值、对应红黑树结点、 虚拟运行时vruntime 等。

4）sched_class：把 调度策略(算法)抽象成调度类 ，包含一组通用的调度操作接口。接口和实现是分离，可以根据调度接口去实现不同的调度算法，使一个Linux调度程序可以有多个不同的调度策略。

1） 关闭内核抢占 ，初始化部分变量。获取当前CPU的ID号，并赋值给局部变量CPU， 使rq指向CPU对应的运行队列 。 标识当前CPU发生任务切换 ，通知RCU更新状态，如果当前CPU处于rcu_read_lock状态，当前进程将会放入rnp-> blkd_tasks阻塞队列，并呈现在rnp-> gp_tasks链表中。 关闭本地中断 ，获取所要保护的运行队列的自旋锁， 为查找可运行进程做准备 。

2） 检查prev的状态，更新运行队列 。如果不是可运行状态，而且在内核态没被抢占，应该从运行队列中 删除prev进程 。如果是非阻塞挂起信号，而且状态为TASK_INTER-RUPTIBLE，就把该进程的状态设置为TASK_RUNNING，并将它 插入到运行队列 。

3）task_on_rq_queued(prev) 将pre进程插入到运行队列的队尾。

4）pick_next_task 选取将要执行的next进程。

5）context_switch(rq, prev, next)进行 进程上下文切换 。

1) 该进程分配的CPU时间片用完。

2) 该进程主动放弃CPU(例如IO操作)。

3) 某一进程抢占CPU获得执行机会。

Linux并没有使用x86 CPU自带的任务切换机制，需要通过手工的方式实现了切换。

进程创建后在内核的数据结构为task_struct ， 该结构中有掩码属性cpus_allowed，4个核的CPU可以有4位掩码，如果CPU开启超线程，有一个8位掩码，进程可以运行在掩码位设置为1的CPU上。

Linux内核API提供了两个系统调用 ，让用户可以修改和查看当前的掩码：

1) sched_setaffinity()：用来修改位掩码。

2) sched_getaffinity()：用来查看当前的位掩码。

在下次task被唤醒时，select_task_rq_fair根据cpu_allowed里的掩码来确定将其置于哪个CPU的运行队列，一个进程在某一时刻只能存在于一个CPU的运行队列里。

在Nginx中，使用了CPU亲和度来完成某些场景的工作：

worker_processes      4;

worker_cpu_affinity 0001001001001000;

上面这个配置说明了4个工作进程中的每一个和一个CPU核挂钩。如果这个内容写入Nginx的配置文件中，然后Nginx启动或者重新加载配置的时候，若worker_process是4，就会启用4个worker，然后把worker_cpu_affinity后面的4个值当作4个cpu affinity mask，分别调用ngx_setaffinity，然后就把4个worker进程分别绑定到CPU0～3上。

worker_processes      2;

worker_cpu_affinity 01011010;

上面这个配置则说明了两个工作进程中的每一个和2个核挂钩。

进程调度算法Linux进程调度算法

这次介绍一下操作系统的进程调度算法

• 操作系统的调度分为三种：1.远程调度（创建新进程）；2.中程调度（交换功能的一部分）；3.短程调度（下次执行哪个进程）

这次讲述的就是短程调度，可以简单的看作咱们平时所说的进程调度啦

当发生下面几种情况的时候会调用短程调度器，然后就看下次执行那个进程啦

• 时钟中断
• I/O中断
• 操作系统调用
• 信号（如信号量）

 

• 进程调度算法：
• • 先来先服务（FCFS）
  • 短作业优先（SPN）
  • 最短剩余时间（SRT）
  • 时间片轮转
  • 最高响应比优先
  • 公平共享调度

 

 

• 先来先服务

就和名字一样，哪个进程先来就先获得处理器时间，，用一个队列暂存等待处理器的进程，优点是实现简单（太简单了吧喂），缺点，遇到那种又臭又长的进程就很不爽了，好比食堂打饭，前面的人不买一直问，后面的人一直排队，那么后面的人就怎么了呢？后面的人就饥饿！同时如果现在有一个马上就要饿死的人急需吃饭，这就很尴尬了（紧急的进程无法处理，优先级高的进程处于饥饿状态），所以有了优先级队列的先来先服务算法，这样也不是很好，因为总有又臭又长的进程，排队是谁都不乐意的吧，而且处理器时间就不公平了。

• 短作业优先

因为先来先服务不好，所以有了短作业优先，通过设置执行时间短的进程作业的优先级为高来实现，也很简单粗暴，就是说进程时间越短就越先执行，看着是比较好了，不浪费时间了，但是有没有想过长进程的感受，来了一群短的进程，然后一直来短进程，这是要饿死长进程的节奏，人家长有错么？如果是可抢占的方式（见最短剩余时间版本），就更惨了，只要来了更短的就别想好好执行了。。。

• 最短剩余时间

就是刚才说的短作业优先的抢占版本，说过他的缺点了，当前执行的进程还剩10个时间单位，但是一直来了一群只要2个时间单位就跑完的进程，那当前的进程就会被抢占，然后含恨饿死。。

• 时间片轮转

既然上面几种算法都有可能出现饥饿进程，那么我就干脆让每个进程都执行那么一会，这样不就比较公平了？每个进程都有机会在处理器上跑，看起来很和谐，但是还是没有解决优先级的问题，优先级不好控制，比如有什么紧急的进程需要立即执行，就不好办了。而且每个进程的具体情况也是不一样的，比如有I/O消耗型进程，和处理器消耗型进程，在同样的事件片里真正占用处理器的时间是不一样的，而我们是真正占用处理器的时间希望能一样的，这样就公平了嘛。这样看来，时间片轮转也是有缺点的。

• 最高响应比优先

什么是响应比？看一下这个公式：R=(w+s)/s，其中R是响应比，w是等待处理器的时间，s是期待的服务时间，简单的来说响应比就是，进程从加入等待队列开始一直到执行完毕经历的时间除以进程使用处理器的时间，这个响应比比较高的就证明该进程等待比较久了，它估计会很饿，先让它吃！

• 公平共享调度

Linux系统中普通进程使用的调度方法就是公平共享调度的一个实例，被称作完全公平调度算法（CFS），虽然一定不可能公平。。。详情参照我的另一篇博客。。传送门召唤！！：http://www.cnblogs.com/lenomirei/p/5516872.html

• Linux系统中的进程调度方案

Linux在进行进程调度的时候把进程分为两种：1.普通进程；2.实时进程

实时进程的优先级永远比普通进程的优先级高，也就是说实时进程只要来了就可以抢占普通进程，而且还抓住处理器就不撒手，直到所有的实时进程都执行完毕，才会把处理器让出来给普通进程使用

之前也说了，普通进程的调度采用的是完全公平调度（CFS）对应的是SCHED_NORMAL

而实时进程采用的调度方法就比较简单粗暴了，Linux提供了两种实时调度策略：SCHED_FIFO和SCHED_RR。

SCHED_FIFO：简单的先入先出的调度算法，不使用时间片，只可能被更高优先级的FIFO或者SCHED_RR抢占

SCHED_RR：时间片轮转的方式，优先级比SCHED_FIFO还要高，可以抢占SCHED_FIFO

实时进程的调度没有实时优先级这一说法，采用的是静态优先级，一开始定好优先级之后就不会改变了。