上下文切换
- 切换CPU的当前任务,从一个进程/线程到另一个
- 保存当前进程/线程在PCB/TCP中执行上下文(CPU状态)
- 读取下一个进程/线程的上下文
CPU调度
从就绪队列中挑选一个进程/线程作为CPU将要运行的下一个进程/线程
调度程序:挑选进程/线程的内核函数
什么时候进行调度
从一个状态到另一个状态会触发调度。
内核运行调度程序的条件(满足一条即可)??
调度原则
执行模型:程序在CPU突发和I/O中交替
-
每个调度决定都是关于在下一个CPU突发时将那个工作交给CPU
-
在时间分片机制下,进程可能在结束当前CPU突发前被迫放弃CPU
-
减少相应时间
-
减少平均相应时间的波动
-
增加吞吐量
-
减少等待时间
低延迟调度增加了交互式表现
如果移动了鼠标,但是屏幕中的光标却没动,我可能会重启电脑。
但是操作系统需要保证吞吐量不受影响
我想要结束长时间的编程,所以操作系统必须不时进行调度,即使存在许多交互任务。
-吞吐量是操作系统的计算带宽
公平的定义
举例
- 保证每个进程占用相同的CPU时间
- 这公平么?如果一个用户比其他用户运行更多的进程怎么办
公平通常会增加平均相应时间。
调度算法
FCFS 先来先服务
SPN 短进程优先
HRRN 最高响应比优先
Round Robin 轮询
使用时间切片和抢占轮流执行任务
Multilevel Feedback Queues 多级反馈队列
Fair Share Scheduling 公平共享调度
先来先服务
FCFS,可能前面有一个进程时间很长,从而影响整个系统的周转时间。
短进程优先(最短剩余时间)
可以是非抢占式的短进程优先,最短时间的进程跟在当前执行进程的后面。
可抢占(SRT)最短剩余时间。
最高相应比优先
轮询算法
设计一个时间片,让各进程轮流占用CPU
花销: 额外耳洞上下文切换
时间量子太大,等待时间过长,极限情况退化成FCFS
时间量子太小,反应迅速,但是。。。吞吐量由于大量的上下文切换开销收到影响。
多级队列
设置不同的优先级,前台需要交互,轮询,后台处理 - FCFS
多级反馈队列,CPU密集型任务的优先级下降很快,I/O密集型任务停留在高优先级。
时间量子大小随优先级级别增加而增加
如果任务在当前的时间量子中没有完成,则降到下一个优先级。
评价
确定性建模
确定一个工作量,然后计算每个算法的表现
队列模型
用来处理随机工作负载的数学方法
实现/模拟:
FCFS 简单
SPN / SRT 不公平,可能产生饥饿状态
最高响应比优先
优先权 = (等待时间 + 要求服务时间) / 要求服务时间 = 响应时间 / 要求服务时间
首先,短作业优先权高,然后呢长作业呢越等,等待时间越长,所以呢优先权就越高。
基于SPN调度改进,不可抢占
Round Robin
多级反馈队列