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

本文探讨了多级反馈队列(MLFQ)调度策略中的关键细节,重点关注如何平衡CPU密集型和IO密集型进程的优先级。通过调整规则4和新增规则5,避免了长时间运行的进程被饿死的问题,以及恶意占用CPU资源的可能性。规则4确保每个进程在优先级队列中累计运行时间,而非每次重新进入队列时获得新时间片。规则5则定时将所有进程提升到最高优先级队列,保证了长时间运行进程的执行机会。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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

 

进程可以大致分为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。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值