你不知道的事——关于多级反馈队列MLFQ的一些细节

多级反馈队列的基本原理此处不再阐述了。这里主要指出几个我关注到的细节而网上大部分的博客都没有提到的，并不全面。更多多级反馈队列的细节请参阅参考资料等。

 

进程可以大致分为CPU密集型的进程（CPU-bound jobs）和IO密集型的进程（I/O-bound jobs），而一般而言，对于IO密集型型进程，我们希望它更快得到处理。因为这类进程需要和用户进行交互，占用CPU时间少，优先处理它们能够使得电脑显得运行得更快。因此，在进程调度过程中，我们总是希望IO密集型进程的优先级比CPU密集型进程高。CPU密集型进程在进程调度中，每当它用完了分配的时间片，就会像石头一样落到低一层的优先级队列中。

在旧一点的MFLQ规则中，可以看到对IO密集型进程是非常“袒护”的。4a的效果即CPU密集型进程将逐渐降低其优先级，让IO密集型进程先运行。4b则使得IO密集型进程在IO中断后再次回到同一级的队列中，尽快得到处理。（在有些进程调度算法中，被IO中断的进程甚至会回到更高一级的优先级队列中，以获得更快的处理。）

然而，Rule 4a和4b会产生占用CPU时间长的进程被饿死的情况。“如果系统中有太多的交互作业，它们将联合起来消耗所有的CPU时间，因此长时间运行的作业将永远不会收到任何CPU时间(它们会饿死)。即使在这种情况下，我们也想在这些工作上取得一些进展。”同时，这也给了一些不怀好意的程序可乘之机。假如一个进程总是在它的时间片即将结束前发起IO中断，那么它就可以一直留在这一优先级中，占用CPU资源。为了解决这两个问题，我们把上面的规则修改一下，并增加Rule 5。

Rule 4:我们不再像基本的多级反馈队列的规则一样，每次重新进入一级队列中，就分配一个时间片来计时，而是计算每个进程在一个优先级队列中运行的总时间。也就是，因为IO中断的进程在完成IO操作后回到队列中时，并不重新占有一个新的时间片，而是继续使用之前剩下的时间。这样一来，所有的进程在用完分配的时间时就必须落入下一优先级的队列中，防止恶意占用CPU。

Rule 5:经过一段固定的时间，把所有的进程都重新移入最高优先级的队列中(Boost)。这解决了两个问题：

1. 防止运行时间长的进程被饿死。因为如果系统中有太多的交互作业，它们将联合起来消耗所有的CPU时间，一直抢占运行，因此长时间运行的作业将收不到任何CPU时间，无法运行。而固定一段时间将所有进程放入最高优先级的队列，能够保证所有进程都能够得到CPU时间，而不会被饿死。
2. 当一个占用CPU多的进程成为一个交互性的进程的时候能够拥有高的优先级。

 参考资料（按推荐顺序排序）：

1. Maria Hybinette, UGA Maria Hybinette, UGA. CSCI [4|6] 730 Operating Systems. CPU Scheduling.
2. Scheduling: The Multi-Level Feedback Queue (翻译版：多级反馈队列)
3. Henri Casanova ([email protected]). CPU Scheduling ICS332 — Operating Systems.
4. lass.cs.umass.edu. Multilevel Feedback Queues (MLFQ)
5. cs.umd.edu. CMSC 412: operating systems
6. Multilevel Feedback Queue Scheduling Algorithm