多级反馈队列的基本原理此处不再阐述了。这里主要指出几个我关注到的细节而网上大部分的博客都没有提到的,并不全面。更多多级反馈队列的细节请参阅参考资料等。
进程可以大致分为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。