调度：多级反馈队列

1. MLFQ：基本规则

MLFQ 中有许多独立的队列（queue），每个队列有不同的优先级（priority level）。任何时刻，一个工作只能存在于一个队列中。

MLFQ 总是优先执行较高优先级的工作（即在较高级队列中的工作）。

每个队列中可能会有多个工作，因此具有同样的优先级。在这种情况下，我们就对这些工作采用轮转调度。

MLFQ根据观察到的行为调整任务的优先级。例如，如果一个工作不断放弃CPU 去等待键盘输入，这是交互型进程的可能行为，MLFQ 因此会让它保持高优先级。相反，如果一个工作长时间地占用 CPU，MLFQ 会降低其优先级。通过这种方式，MLFQ 在进程运行过程中学习其行为，从而利用工作的历史来预测它未来的行为。

MLFQ 的两条基本规则：

规则 1：如果 A 的优先级 > B 的优先级，运行 A（不运行 B）。

规则 2：如果 A 的优先级 = B 的优先级，轮转运行 A 和 B。

2. 尝试1：如何改变优先级

在一个工作的生命周期中，MLFQ 如何改变其优先级？

工作负载：既有运行时间很短、频繁放弃 CPU 的交互型工作；也有需要很多 CPU 时间、响应时间却不重要的长时间计算密集型工作。

优先级算法调整1：

规则 3：工作进入系统时，放在最高优先级（最上层队列）。

规则 4a：工作用完整个时间片后，降低其优先级（移入下一个队列）。

规则 4b：如果工作在其时间片以内主动释放 CPU，则优先级不变。

说明：

如果不知道工作是短工作还是长工作，那么就在开始的时候假设其是短工作，并赋予最高优先级。如果确实是短工作，则很快会执行完毕，否则将被慢慢移入低优先级队列，而这时该工作也被认为是长工作了。通过这种方式，MLFQ 近似于 SJF。
假设交互型工作中有大量的 I/O 操作（比如等待用户的键盘或鼠标输入），它会在时间片用完之前放弃 CPU。在这种情况下，我们不想处罚它，只是保持它的优先级不变。

存在的问题：

饥饿（starvation）问题。如果系统有“太多”交互型工作，就会不断占用
CPU，导致长工作永远无法得到 CPU。
愚弄调度程序（game the scheduler）。
一个程序可能在不同时间表现不同。一个计算密集的进程可能在某段时间表现为一个交互型的进程。用目前的方法，它不会享受系统中其他交互型工作的待遇。

3. 尝试2：提升优先级

否避免饥饿问题，让 CPU 密集型工作也能取得一些进展。解决问题1, 3。

一个简单的思路是周期性地提升（boost）所有工作的优先级。

优先级算法调整2：

规则 5：经过一段时间 S，就将系统中所有工作重新加入最高优先级队列。

时间段 S 如果设置得太高，长工作会饥饿；如果设置得太低，交互型工作又得不到合适的 CPU 时间比例。

4. 尝试3：更好的计时方式

为 MLFQ 的每层队列提供更完善的 CPU 计时方式（accounting），解决问题 2 。

调度程序应该记录一个进程在某一层中消耗的总时间，而不是在调度时重新计时。只要进程用完了自己的配额，就将它降到低一优先级的队列中去。不论它是一次用完的，还是拆成很多次用完。重写规则 4a 和 4b 。

优先级算法调整3：

规则 4：一旦工作用完了其在某一层中的时间配额（无论中间主动放弃了多少次CPU），就降低其优先级（移入低一级队列）。

5. MLFQ 调优及其他问题

如何配置一个调度程序：

配置多少队列？
每一层队列的时间片配置多大？
该多久提升一次进程的优先级？（S）
…

6. MLFQ：小结

调度规则：

规则 1：如果 A 的优先级 > B 的优先级，运行 A（不运行 B）。

规则 2：如果 A 的优先级 = B 的优先级，轮转运行 A 和 B。规则 3：工作进入系统时，放在最高优先级（最上层队列）。

规则 4：一旦工作用完了其在某一层中的时间配额（无论中间主动放弃了多少次CPU），就降低其优先级（移入低一级队列）。

规则 5：经过一段时间 S，就将系统中所有工作重新加入最高优先级队列。

MLFQ 不需要对工作的运行方式有先验知识，而是通过观察工作的运行来给出对应的优先级。通过这种方式，MLFQ 可以同时满足各种工作的需求：对于短时间运行的交互型工作，获得类似于 SJF/STCF 的很好的全局性能，同时对长时间运行的CPU 密集型负载也可以公平地、不断地稳步向前。