c - 轮询时间调度中的时间片

Question

如果循环调度程序的时间片非常大（比如说太大），我应该在操作系统中期望什么样的性能影响？

我唯一的想法是需要大量时间的流程会受益，但大多数流程使用的时间很少，所以会导致完成所有较小流程的延迟？

示例：时间片为 50，进程 P1=400, P2=10, P3 = 150, P4 = 20, P5 = 10, P6 = 10

这是我最好的猜测，我想知道你们是否可以分享任何关于时间片太小或太大的东西。

Answer 1

循环法的问题是任务不相等。

对于 CPU 密集型任务；如果你有一项极其重要的任务和数千个不重要的任务，那么所有这些不重要的任务都会削弱重要任务的执行。对于这种情况，时间片有多大并不重要。

对于 IO 绑定任务，轮询会导致不良延迟。如果一个重要任务解除阻塞（例如在调用“sleep()”后唤醒，接收它正在等待的文件 IO 等），那么它可能必须等待数千个不重要的任务在重要任务之前完成它们的时间片有机会做任何事。减少时间片长度将减少重要任务开始做一些有用的事情所需的时间，但也会减少重要任务做一些有用的事情的时间。

注意：您可能想通过将解除阻塞的任务放在列表的开头来“修复”这个问题。在这种情况下，一项重要的任务可能会因为不重要的任务一直在睡觉和醒来而永远被饿死。

从本质上讲，循环是一堆“无用”的热气腾腾的东西，除非你用完全不同的调度算法替换它，否则你做什么都不重要，至少对不同任务的重要性/优先级有一定的尊重。

举一个过于简单的例子；您可以有 3 个不同的任务优先级，其中操作系统只运行它可以运行的最高优先级任务（包括确保较高优先级的任务立即抢占较低优先级的任务），并且循环用于具有相同优先级的任务。在这种情况下，您可以为不同的优先级设置不同的时间片长度（例如，高优先级任务仅获得 1 毫秒，中优先级任务获得 10 毫秒，低优先级任务获得 125 毫秒）。

对于“不太简单”的示例；您可以有几种完全不同的调度策略（例如，一种用于实时任务，一种用于普通任务，一种用于后台/空闲任务），它们都使用不同的方法（例如，最早的截止日期优先，可变时间片等）；每个调度策略有 256 个任务优先级。

Answer 2

从时间切片的角度来看，有两种极端情况会降低性能。如果时间片是：

1. 太大：导致小进程等待很长时间，如果时间片更小，它们本可以更早完成。此外，这对于需要更小但频繁的 CPU 时间的交互式进程也是不利的。
2. 太小：导致频繁的上下文切换，这相当于显着的开销。

从历史上看，操作系统开发人员一直在努力在这两个极端之间取得平衡，并且有各种基于优先级的算法被循环吸收以获得更好的性能。