嵌入式操作系统(2):调度
一、调度原则
何时调度:进程状态变化的时候
目标:
- 减少响应时间(及时处理用户的输出并且尽快将输出提供给用户
- 减少平均响应时间的波动(在交互系统中,可虞可预测性比高差异低平均更重要
- 增加吞吐量–两个方面(1、减少开销(操作系统开销,上下文切换)2、系统资源的高效利用(CPU,I/O设备)
- 减少等待时间
评价调度算法指标:
- CPU利用率:CPU处于忙碌状态所占时间的百分比
- 吞吐量:在单位时间内完成的进程数量(相当于操作系统的带宽)
- 周转时间:一个进程从初始化到结束,包括所有等待时间所花费的时间。 (周转时间 = 等待时间 + 执行时间)
- 等待时间:进程在就绪队列中的总时间
- 响应时间:从一个请求被提交到产生第一次响应所花费的总时间(相当于操作系统的计算延迟)
公平性:
- 保证每个进程都占用相同的cpu时间
- 保证每个进程都等待相同的时间
- 公平通常会增加平均响应时间
运行调度程序的情况:
- 一个进程从运行状态变化为等待状态
- 一个进程被杀死
调度中抢占的情况:
- 调度程序在中断被响应后执行
- 当前的进程从运行切换到就绪,或者一个进程从等待切换到就绪
- 当前运行的进程可以被换出
二、调度算法
调度算法有三类:
- 通常操作系统设计的基本调度算法
- 嵌入式设备实时的调度算法
- 针对多处理器的调度算法与考虑
2.1. 基本调度算法
- FCFS (先来先服务) (First Come, First Served)
- SPN(SJF)SRT (短进程优先(短作业优先)剩余时间优先) Shortest Process Next(Shortest Job First) Shortest Remaining Time
- HRRN (最高响应比优先) Highest Response Ratio Next
- Round Robin (轮循) 使用时间切片和抢占来轮流执行任务
- Multilevel Feedback Queues (多级反馈队列) 优先级队列中的轮循
- Fair Share Scheduling (公平共享调度)
先来先服务调度【FCFS】
规则:
- 先来的先占用CPU,即先到先得(队列)。
- 如果前一个进程在Running中发生堵塞,则队列中下一个会得到CPU。
举个栗子:
如果进程执行时间短的先到的话周转时间小,反之则大。
优点:简单
缺点:
- 平均等待时间波动较大,平均的周转时间也会比较大
- 花费时间少的任务可能排在花费时间长的任务后面,没有考虑抢占
- 可能导致I/O和CPU之间的重叠处理(cpu密集型进程会导致I/O设备闲置时,I/O密集型进程也在等待)
短任务优先算法【SPN(SJF)SRT】
规则:
- 队列中的排序以执行时间的长短来排序,执行时间短的进程排在前边。
当一个进程执行时,来了一个进程比当前最短的还短的情况进行分类:
- 可抢占:将这个时间更短的程序与正在执行的程序剩余所需要执行的时间进行比较,如果跟多,这打断正在执行的程序(SRT)
- 不可抢占:将这个时间更短的程序排在前面,但是继续执行本来在执行的进程(SPN)
举个栗子:
优点:
- 周转时间最短
缺点:
- 可能导致饥饿(长任务排队排不完,有违公平性
- 需要预估未来(预估算法
- 如果用户欺骗就杀死进程
最高响应比优先算法【HRRN】
规则:
- 在SPN调度的基础上改进
改进方式:
用R = (w + s) / s,代替原有的普通执行时间。其中w为等待时间;s为执行时间。并且R值越高表示等待的时间越长,就会优先的调度这种进程。
优点:
- 充分的考虑到了进程的等待时间,所有之前的饥饿现象会得到有效的化解。
缺点:
- 不可抢占
- 依然需要知道执行的时间是多长,所以还是要预估
轮循算法【RR】
规则:
- 各个cpu轮流占用cpu去执行,在叫做量子(或时间切片)的离散单元中分配处理器
- 时间片结束后,切换到下一个准备好的进程
举个栗子:
其中时间片设定应满足:维持上下文切换开销处于1%以内,这样的情况下99%的时间都是在进程的执行中
特点:
- RR开销:上下文切换时间
- 时间片过短:上下文切换开销过大
- 时间片过大:等待时间过长,容易退化成FCFS
多级反馈队列【MLFQ】
规则:
- 完成高优先级的进程,待其完成了所以的任务之后,再去完成第优先级的进程
- 如果任务在当前的时间量子中没有完成,则降到下一个优先级
- 每个优先级的执行为RR算法
- 时间片大小随优先级级别增加而增加
- 进程各阶段的特点来调整其在队列中的级别
示意图:
特点:
- 能够区分进程在动态执行过程中动态的调整进程优先级
- IO密集型的任务可以很快的执行
- CPU密集型的任务放在优先级较低位置
公平共享调度【FSS】
规则:
- 一些用户组比其他组更重要
- 保证不重要的组无法垄断资源
- 未使用的资源按照每个组所分配的资源比例来分配
- 没有达到资源使用率目标的组获得更高的优先级
PS:在linux中使用的就是一种公平共享调度。
2.2. 实时调度(实时系统)
性能指标:
- 时间约束的及时性(deadlines)
- 速度和平均性能相对不重要
分类:
- 强实时系统:需要在保证的时间内完成重要的任务,必须完成
- 弱实时系统:要求重要的进程的优先级更高,尽量完成,并非必须
时间轴:
- Released :让进程处于就绪态的时间
- Execution time:执行时间
- Absolute deadline:绝对的截止时间,任务的执行不可以操作这个时间
- Relative deadline:相对截止时间,因为任务是间隔的,一段时间完成一个任务
若任务为周期任务,其周期必须大于执行时间
硬时限:(对应于硬实时系统)
- 如果错过了最后的期限,可能会发生灾难性或非常严重的后果
- 必须验证:在最坏的情况下也能够满足时限
- 保证确定性
软时限:(对应于软实时系统)
- 理想情况下,时限应该被最大满足。如果有时限没有被满足,那么就相应地降低要求
- 尽量大努力去保证
调度算法:
- RM(Rate Monotonic)速率单调调度:任务周期确定优先级
- EDF(Earliest Deadline First)最早期限调度:截止期限确定优先级
速率单调调度【RM】
规则:
- 每个周期性任务会分配一个优先级,它与其周期成反比,即周期越短,优先级越高;周期越长,优先级越低。(优先级为静态的不改变)
- 当较低优先级的进程正在运行并且较高优先级的进程可以运行时,较高优先级进程将会抢占低优先级
举个例子
有两个进程 P1 和 P2。P1 和 P2 的周期分别为 50 和 100,即 ρ1 = 50 和 ρ2= 100。P1 和 P2 的处理时间分别为 t1 = 20 和 t2 = 35。每个进程的截止期限要求。
由周期比较可以看出P1的优先级大于P2
所以甘特图如下所示:
- P1 开始,并在时间 20 完成 CPU 执行,从而满足第一个截止期限。
- P2 在这点开始运行,并运行直到时间 50。此时,它被 P1 抢占,尽管它的 CPU 执行仍有 5ms 的时间。
- P1 在时间 70 完成 CPU 执行,在这点调度器恢复 P2。
- P1 在时间 75 完成 CPU 执行,也满足第一个截止期限。
- 系统一直空闲直到时间 100,这时,P1 再次被调度。
单调速率调度可认为是最优的,因为如果一组进程不能由此算法调度,它不能由任何其他分配静态优先级的算法来调度。对于CPU利用率比较高的进程,它们不能使用单调速率算法来调度。
尽管是最优的,然而单调速率调度有一个限制,CPU 的利用率是有限的,并不总是可能完全最大化 CPU 资源。调度 N 个进程的最坏情况下的 CPU 利用率为:
对于具有一个进程的系统,CPU 利用率是 100%;但是当进程数量接近无穷时,它大约接近 69%。对于具有两个进程的系统,CPU 利用率是 83%。图 1 和图 2 调度的两个进程的组合利用率为 75%,因此单调速率调度算法保证能够调度它们。若两个进程的组合利用率为 94%则会出现错误,因此,单调速率调度不能保证它们可以调度以便满足它们的截止期限。例如以下例子:
失败例子
假设进程 P1 具有周期 ρ1=50 和 CPU 执行 t1 = 25。进程 P2 的对应值是 ρ2=80 和 t2 = 35。单调速率调度将为进程 P1 分配较高的优先级,因为它具有较短的周期。两个进程的总 CPU 利用率为0.94。所以甘特图如下所示:
- P1 运行,直到在时间 25 完成 CPU 执行。
- P2 开始运行,并运行直到时间 50,这时它被 P1 抢占;P2 在 CPU 执行中仍有 10ms 的剩余。
- 进程 P1 运行直到时间 75,导致 P2 在时间 85 结束,因而超过了在时间 80 完成 CPU 执行的截止期限。
最早截止时间优先(EDF)
规则:
- 根据截止期限动态分配优先级。截止期限越早,优先级越高;截止期限越晚,优先级越低(实时动态分配)
- 当一个进程可运行时,它应向系统公布截止期限要求。优先级可能需要进行调整,以便反映新可运行进程的截止期限。
以RM的失败例子进行举例:
就可以看出P1&P2都能在期限内完成。
与单调速率调度不一样,EDF 调度不要求进程应是周期的,也不要求进程的 CPU 执行的长度是固定的。唯一的要求是,进程在变成可运行时,应宣布它的截止期限。
EDF 调度具有吸引力的地方是,它是理论上最佳的。从理论上说,它可以调度进程,使得每个进程都可以满足截止期限的要求并且 CPU 利用率将会是 100%。然而,在实际中,由于进程的上下文切换和中断处理的代价,这种级别的 CPU 利用率是不可能的。
2.3. 多处理器调度与优先级反转
未完待续