上下文切换
- 切换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
多级反馈队列