基本概念

多道程序设计的目标是，无论何时都有进程运行，从而最大化CPU利用率。它会有多个进程或线程同时竞争CPU。分时系统的目的是在进程之间快速切换CPU，以便用户在程序运行时能与其交互。为了满足这些目标，进程调度器选择一个可用进程到CPU上执行。单处理器系统不会具有多个正在运行的进程。如果有多个进程，那么其余的需要等待CPU空闲并能重新调度。

CPU-I/O执行周期

CPU的调度成功取决于观察到的进程属性: 进程执行包括周期进行CPU执行和I/O等待。进程在这两个状态之间不断交替。进程执行从CPU执行开始，之后I/O执行；接着另一个CPU执行，接着另一个I/O执行；等等。最终，最后的CPU执行通过系统请求结束，终止执行。

CPU密集型进程-I/O密集型进程

图a中的进程花费了绝大多数时间在计算上，称为CPU密集型。

图b中的进程则在等待I/0上花费了绝大多数时间，称为I/O密集型。

典型的CPU密集型进程具有较长时间的CPU 集中使用和较小频度的I/O等待。

I/O密集型进程具有较短时间的CPU集中使用和频繁的1/0等待。它是I/O类的，因为这种进程在I/O请求之间较少进行计算，并不是因为它们有特别长的I/O请求。在I/O开始后无论处理数据是多还是少，它们都花费同样的时间提出硬件请求读取磁盘块。

随着CPU变得越来越快，更多的进程倾向为I/O密集型。因为CPU的改进比磁盘的改进快得多，结果是，未来对I/O密集型进程的调度处理似乎更为重要。这里的基本思想是，如果需要运行I/O密集型进程，那么就应该让它尽快得到机会，以便发出磁盘请求并保持磁盘始终忙碌。

何时调度

出现以下情形需要调度。

1、在创建一个新进程之后，需要决定是运行父进程还是运行子进程。由于这两种进程都处于就绪状态，所以这是一种正常的调度決策，可以任意決定，也就是说，调度程序可以合法选择先运行父进程还是先运行子进程。
2、在一个进程退出时必须做出调度决策。一个进程不再运行（因为它不再存在），所以必须从就绪进程集中选择另外某个进程。如果没有就绪的进程，通常会运行一个系统提供的空闲进程。
3、当一个进程阻塞在I/O和信号量上或由于其他原因阻塞时，必须选择另一个进程运行。有时，阻塞的原因会成为选择的因素。例如，如果A是一个重要的进程，并正在等待B退出临界区，让B随后运行将会使得B退出临界区，从而可以让A运行。
4、在一个I/O中断发生时，必须做出调度决策。如果中断来自I/O设备，而该设备现在已经完成了上作，某些被阻塞的等待该I/O的进程就成为可运行的就绪进程了。

非抢占式调度算法这种情况下，一旦进程处于运行状态，它就不断执行直至终止(自动释放CPU)。或者因为等待I/O资源，或者请求某些操作系统服务而阻塞自己。即使该进程运行了若干个小时，它也不会被强迫挂起。这样做的结果是，在时钟中断发生时不会进行调度。在处理完时钟中断后，如果没有更高优先级的进程等待到时，则被中断的进程会继续执行。

抢占式调度算法进程运行某个固定时段的最大值。如果在该时段结束时，该进程仍在运行，它就被挂起，而调度程序挑选另一个进程运行（如果存在一个就绪进程）。进行抢占式调度处理，需要在时间间隔的末端发生时钟中断，以便把CPU控制返回给调度程序。如果没有可用的时钟，那么非抢占式调度就是惟一的选择了。

调度准则

不同的CPU调度算法具有不同属性，选择一个特定会对某些进程更为有利。为了选择算法以便用于特定情境，必须考虑各个算法的属性。

为了比较CPU调度算法，可以采用许多比较准则。

1、周转时间(面向用户，与性能相关)。指一个进程从提交到完成之间的时间间隔，包括实际执行时间加上等待资源（包括等待进入内存、在就绪队列中等待、在CPU上执行和I/O执行）的时间。
2、响应时间(面向用户，与性能有关)。对一个交互进程，这是指从提交一个请求到开始接收响应之间的时间间隔。通常进程在处理该请求的同时，就开始给用户产生一些输出。因此从用户的角度来看，相对于周转时间，这是一种更好的度量。该调度原则应该试图达到较低的响应时间，并且在响应时间可接受的范围内，使得可以交互的用户数目达到最大。
3、最后期限(面向用户，与性能相关)。当可以指定进程完成的最后期限时，调度原则将降低其他目标，使得满足期限的作业数目的百分比达到最大。
4、可预测性(面向用户，与性能相关)。无论系统的负载如何，一个给定的工作运行的总时间量和总代价是相同的。用户不希望响应时间或周转时间的变化太大。这可能需要在系统工作负载大范围抖动时发出信号。
5、吞吐量(面向系统，与性能相关)。调度策略应该试图使得每个时间单位完成的进程数目达到最大。这是对可以执行多少工作的一种度量。它明显取决一个进程的平均执行长度。对于长进程，吞吐量可能为每小时一个进程。对于短进程，吞吐量可能为每秒十个进程。
6、处理器利用率(面向系统，与性能相关)。这是处理器忙的时间百分比。对昂贵的共享系统来说，这是一个重要的准则。
7、公平性(面向系统，其他)。在没有来自用户的指导或其他系统提供的指导时，进程应该被平等地对待，没有一个进程会处于饥饿状态。
8、强制优先级(面向系统，其他)。当进程被指定了优先级后，调度策略应该优先选择高优先级的进程。
9、平衡资源(面向系统，其他)。调度策略将保持系统中所有资源处于忙碌状态，较少使用紧缺资源的进程应该受到照顾。

优先级的使用

在许多系统中，每个进程都被指定一个优先级，调度程序总是选择具有较高优先级的进程。下图说明了优先级的使用。

一组就绪队列，按优先级递减的顺序排列: RQ0、RQ1、...、RQn。当进行一次调度选择时，调度程序从优先级最高的队列(RQ0)开始。如果队列中有一个或多个进程，则使用某种调度策略选择其中一个: 如果RQ0为空，则检查RQ1，接下来的处理类似。

优先级调度方案的一个问题是低优先级的进程可能会长时间处于饥饿状态。如果一直有高优先级的就绪进程，就会出现这种情况。如果不希望出现这种情况，一个进程的优先级应该随着它的时间或执行历史而变化。

单处理器调度

与非抢占策略相比，抢占策略可能会导致较大的开销，但是可能对所有进程会提供较好的服务，因为它们避免了任何一个进程独占处理器太长的时间。另外，通过使用有效的进程切换机制(尽可能地获得硬件的帮助)，以及提供比较大的内存，使得大部分程序都在内存中，可使抢占的代价相对比较低。

各种抢占策略特点

先来先服务(FCFS)

在所有调度算法中，最简单的是非抢占式的算法-先来先服务。也叫先进先出(FIFO)或严格排队方案。

当每个进程就绪后，它加入就绪队列。考量指标是该算法的周转时间。

优点

先来先服务算法易于理解并且便于在程序中应用。算法中，一个单链表记录了所有就绪进程。要选取一个进程运行，只要从该队列的头部移走一个进程即可。要添加一个新的作业或阻塞一个进程，只要把该作业或进程附加在相应队列的末尾即可。

缺点

相对于I/O密集型进程，该算法更有利于CPU密集型的进程。有几个缺点。

短作业/任务/进程可能排在长进程的后面
平均等待时间波动较大
I/O资源和CPU资源的利用率较低

有一组进程。其中一个进程大多数时候使用CPU(CPU密集型)，还有许多进程大多数时候进行I/0操作(I/0密集型)。如果一个CPU密集型的进程正在运行，则所有I/0密集型的进程必须等待。有一些进程可能在I/0队列中（阻塞态），但是当CPU密集型的进程正在执行时，它们可能移回就绪队列。这时，大多数或所有I/O设备都可能是空闲的，即使它们可能还有工作要做。在当前正在运行的进程离开运行状态时，就绪的I/0 密集型的进程迅速地通过运行态，又阻塞在I/0 事件上。如果CPU密集型的进程也被阻塞了，则处理器空闲。因此，先来先服务 可能导致CPU和I/0设备都没有得到充分利用。

FCFS 自身对于单CPU系统并不是很有吸引力的选择。但是，它通常与优先级策略相结合，以提供一种更有效的调度方法。因此，调度程序可以维护许多队列，每个优先级一个队列，每个队列中的调度基于先来先服务原则。在后面讨论反馈调度时，可以看到这类系统的一个例子。

最短作业优先

SPN：Shortest Process Next（短进程优先算法）
SJF：Shortest Job First（短作业优先算法）
SRT：Shortest Remaining Time（短剩余时间优先算法）

最短作业优先适用于运行时间可以预知的非抢占式的调度算法。它的原则是下一次选选择预计处理时间最短的进程。

假如，一家保险公司，因为每天都做类似的工作，所以人们可以相当精确地预测处理1000个索赔的一批作业需要多少时间。当输人队列中有若干个同等重要的作业被启动时，调度程序应使用最短作业优先 (shortest job first）算法。

这里有4个作业A，B、C、D，运行时间分别为8、4、4、4分钟。若按图a运行，则A的周转时间为8分钟，B为12分钟，C为16分钟，口为20分钟，平均为14分钟。

使用最短作业优先算法运行这4个作业，如图b所示。目前周转时间分别为4、8、12和20分钟，平均为11分钟。可以证明最短作业优先是最优的。

有必要指出，只有在所有的作业都可同时运行的情形下，最短作业优先算法才是最优化的。

最短剩余时间优先算法

最短剩余时间优先（Shortest Remaining Time, SKT）是针对SPN增加了抢占机制的版本。在这种情况下，调度程序总是选择预期剩余时间最短的进程。当一个新进程加入到就绪队列时，它整个时间同正在运行的进程剩余时间做比较。如果它比当前运行的进程具有更短的剩余时间，只要新进程就绪，调度程序就可能抢占当前正在运行的进程。和SPN一样，调度程序在执行选择函数时必须有关于处理时问的估计，并且存在长进程饥饿的危险。

SRT 不像FCFS 那样偏向长进程，也不像轮转那样会产生额外的中断，从而减少了开销。另一方面，它必须记录过去的服务时间，从而增加了开销。从周转时间来看，SRT 比SPN 有更好的性能，因为相对于一个正在运行的长作业，短作业可以立即被选择运行。

轮转算法

为了减少在FCFS策略下对短作业的不利情况，一种简单的方法是采用基于时钟的抢占策略，最简单的是轮转算法。它是一种最古老、最简单、最公平且使用最广的算法。

每个进程分配一个时间段，称为时间片，即允许该进程在该时间段中运行。

如果在时间片结束时该进程还在运行，则将剥夺CPU并分配给另一个进程。
如果该进程在时间片结束前阻塞或结束，则CPU立即进行切换。

当一个进程用完它的时间片后，就被移到队列的末尾。

从一个进程切换到另一进程需要一定时间管理事物处理-保存和装入寄存器值及内存映像、更新各种表格和列表、清除和重新调入内存/高速缓存等。

时间片

对于轮转算法，最主要的设计问题是时间片的长度。

如果这个长度非常短，则短作业会相对比较快地通过系统。因此，应该避免使用过短的时间片。时间片最好略大于一次典型的交互所需要的时间。如果小于这个时间，大多数进程都需要至少两个时间片。当一个时间片比运行时间最长的进程还要长时，轮转法退化成 FCFS。

假如上下文切换需要1ms，时间片为4ms。那么，CPU在做完4ms有用的工作后，CPU将花费1ms来进行进程切换。因此，CPU时间的20%浪费在管理开销上。这可太多了。

为了提高CPU的效率，我们可以將时间片设置成，比方说，100ms，这样浪费的时间只有1%。但是，如果在一段非常短的时间间隔内到达50个请求，并且对CPU有不同的需求，在一个服务器系统中会发生什么呢？50个进程会放在可运行进程的列表中。如果CPU是空闲的，第一个进程会立即开始执行，第二个直到100ms以后才会启动，以此类推。假设所有其他进程都用足了它们的时间片的话，最不幸的是最后一个进程在获得运行机会之前将不得不等待5秒钟。大部分用户会认为5秒的响应对于一个短命令来说是缓慢的。

另一个因素是，如果时间片设置长于平均的CPU突发时间，那么不会经常发生抢占。相反，在时间片耗费完之前多数进程会完成一个阻塞操作，引起进程的切换。抢占的消失改善了性能，因为进程切换只会发生在确实逻輯上有需要的时候，即进程被阻塞不能够继续运行。

时间片设得太短会导致过多的进程切换，降低了CPU效率，而设得太长又可能引起对短的交互请求的响应时间变长。将时间片设为20ms~50 ms通常是一个比较合理的折中。

在CPU密集型-I/0密集型进程中的使用

轮转算法在通用的分时系统或事务处理系统中都特别有效。它的一个缺点是依赖于CPU密集型的进程和 I/0 密集型的进程的不同。通常I/0 密集型的进程比CPU密集型的进程使用处理器的时间（花费在 I/O 操作之间的执行时间）短。如果既有CPU密集型的进程又有I/0 密集型的进程，就有可能发生如下情况：一个I/0 密集型的进程只使用CPU很短的一段时间，然后因为I/0 而被阻塞，等待 I/0 操作的完成，然后加入到就绪队列；另一方面，一个CPU密集型的进程在执行过程中通常使用一个完整的时间片并立即返回到就绪队列中。因此，CPU密集型的进程不公平地使用了大部分CPU时间，从而导致I/0 密集型的进程性能降低、使用 I0 设备低效、响应时间的变化大。

截屏2024-04-20 17.20.29.png

多级队列调度

就绪队列中的进程可能会被分为不同的类，每个类都有自己的调度需求。例如，常见的划分是前台（交互） 进程和后台（批处理） 进程。这两个类有不同的调度需求。针对这种情况，采用 多级队列调度。

多级队列（MLQ）CPU调度的特点：

多个队列： 在MLQ调度中，进程根据优先级被分为多个队列，每个队列具有不同的优先级。较高优先级的进程被放置在具有较高优先级的队列中，而较低优先级的进程被放置在具有较低优先级的队列中。
分配的优先级： 根据进程的类型、特征和重要性为进程分配优先级。例如，诸如用户输入/输出之类的交互式过程可能比诸如文件备份之类的批处理过程具有更高的优先级。
抢占： MLQ调度中允许抢占，这意味着较高优先级的进程可以抢占较低优先级的进程，并将CPU分配给较高优先级的进程。这有助于确保及时执行高优先级进程。
调度算法： 每个队列可以使用不同的调度算法，具体取决于该队列中进程的要求。例如，循环调度可用于交互式过程，而先来先服务调度可用于批处理。
反馈机制： 可以实施反馈机制来根据进程随时间的行为来调整进程的优先级。例如，如果一个交互进程在较低优先级队列中等待了很长时间，则可以提高其优先级以确保其及时执行。
CPU时间的高效分配： MLQ调度确保具有较高优先级的进程及时执行，同时仍然允许较低优先级的进程在CPU空闲时执行。
不可跨队列： 同一优先级的进程属于某个队列，且不能跨队列。
公平性： MLQ 调度根据不同类型的进程的优先级和要求，为不同类型的进程提供公平的 CPU 时间分配。
可定制： MLQ调度可以定制，以满足不同类型流程的特定要求。
规则一： 如果A的优先级 > B的优先级，运行A(不运行B)

多级队列CPU调度的优点：

调度开销低： 由于进程被永久分配到各自的队列，因此调度开销很低，调度程序只需要选择合适的队列来执行。
高效分配CPU时间： 调度算法保证优先级较高的进程及时执行，同时在CPU空闲时仍允许优先级较低的进程执行。这可确保 CPU 时间的最佳利用。
公平性： 调度算法根据不同类型的进程的优先级和要求，为不同类型的进程提供公平的 CPU 时间分配。
可定制： 可以定制调度算法，以满足不同类型进程的具体要求。每个队列可以使用不同的调度算法，具体取决于该队列中进程的要求。
优先级划分： 根据流程的类型、特征和重要性为流程分配优先级，确保重要流程及时执行。
抢占： 多级队列调度中允许抢占，即高优先级进程可以抢占低优先级进程，将CPU分配给高优先级进程。这有助于确保及时执行高优先级进程。

多级队列CPU调度的缺点：

如果某些较高优先级队列永远不会变空，某些进程可能会缺乏 CPU。可能会导致饥饿。
它本质上是不灵活的。
实现和维护多个队列和调度算法可能会增加复杂性。

时间片轮转

80%CPU的时间分配给前台，20%的CPU的时间分配给后台。

系统进程、交互进程和批处理进程

就绪队列为每一类进程划分为单独的队列。例如，让我们采用三种不同类型的进程：系统进程、交互进程和批处理进程。所有三个进程都有自己的队列。现在，看下图。

上图中的流程描述如下：

系统进程： CPU本身有自己的进程要运行，通常称为系统进程。
交互过程： 交互过程是一种其中应该存在相同类型交互的过程。
批处理： 批处理通常是操作系统中的一种技术，在处理开始之前以批处理的形式将程序和数据收集在一起。****

所有三种不同类型的进程都有自己的队列。每个队列都有自己的调度算法。例如，队列1和队列2使用循环法，而队列3可以使用FCFS来调度其进程。

队列之间的调度： 如果所有队列都有一些进程会发生什么？哪个进程应该获得CPU？为了确定这一点，队列之间的调度是必要的。有两种方法可以做到这一点 –

固定优先级抢占式调度方法—— 每个队列比低优先级队列具有绝对优先级。让我们考虑以下优先级顺序：队列 1 > 队列 2 > 队列 3。根据该算法，除非队列 1 和 2 为空，否则批处理队列（队列 3）中的任何进程都无法运行。如果任何批处理进程（队列 3）正在运行并且任何系统（队列 1）或交互进程（队列 2）进入就绪队列，则批处理进程将被抢占。
时间分片——在这种方法中，每个队列都会获得一定部分的 CPU 时间，并可以用它来调度自己的进程。例如，队列 1 占用 50% 的 CPU 时间，队列 2 占用 30%，队列 3 占用 20% 的 CPU 时间。

多级反馈队列

多级反馈队列调度（MLFQ） CPU 调度类似于多级队列（MLQ）调度，但在此过程中可以在队列之间移动。因此，比多级队列调度效率更高。

多级反馈队列调度（MLFQ）CPU调度的特点：

多队列： 与MLQ调度类似，MLFQ调度根据进程的优先级将进程划分为多个队列。但是，与 MLQ 调度不同，进程可以根据其行为和需求在队列之间移动。
动态调整优先级： 进程的优先级可以根据其行为动态调整，例如它使用了多少 CPU 时间或被阻塞的频率。优先级较高的进程会获得更多的 CPU 时间，而优先级较低的进程会获得较少的 CPU 时间。
时间分片： 每个队列都分配有一个时间量或时间片，它确定该队列中的进程在被抢占并移动到较低优先级队列之前允许使用多少 CPU 时间。
反馈机制： MLFQ 调度使用反馈机制根据进程随时间的行为来调整进程的优先级。例如，如果较低优先级队列中的进程用完其时间片，则可以将其移至较高优先级队列以确保其获得更多 CPU 时间。
抢占： MLFQ调度允许抢占，这意味着高优先级进程可以抢占低优先级进程，以确保其获得所需的CPU时间。
规则一： 如果A的优先级 > B的优先级，运行A(不运行B)
规则二： 如果A的优先级 = B的优先级，轮转/FIFO运行A和B

多级反馈队列调度的优点：

它更加灵活。
它允许不同的进程在不同的队列之间移动。
它通过将等待较低优先级队列太长时间的进程移动到较高优先级队列来防止饥饿。

多级反馈队列调度的缺点：

最佳调度器的选择，需要一些其他的手段来选择值。
它会产生更多的 CPU 开销。
它是最复杂的算法。

多处理器调度

在多处理器调度中，多个 CPU可用，因此负载共享成为可能。然而，与单处理器调度相比，多处理器调度更加复杂。在多处理器调度中，有时处理器是相同的，即同质的，就其功能而言，我们可以使用任何可用的处理器来运行队列中的任何进程。

多处理器调度方法

一种方法是所有调度决策和 I/O 处理均由称为主服务器的单个处理器处理，而其他处理器仅执行用户代码。这很简单并且减少了数据共享的需要。整个场景称为非对称多处理。第二种方法使用对称多处理，其中每个处理器都是自调度的。所有进程可以位于公共就绪队列中，或者每个处理器可以具有其自己的就绪进程专用队列。通过让每个处理器的调度程序检查就绪队列并选择要执行的进程来进一步进行调度。

处理器亲和力

处理器关联性意味着进程与其当前运行的处理器具有关联性。当进程在特定处理器上运行时，会对高速缓存产生一定的影响。进程最近访问的数据填充处理器的高速缓存，因此进程的连续存储器访问通常在高速缓冲存储器中得到满足。现在，如果进程迁移到另一个处理器，则第一个处理器的高速缓存存储器的内容必须失效，并且必须重新填充第二个处理器的高速缓存。由于无效和重新填充缓存的成本很高，大多数 SMP（对称多处理）系统都试图避免进程从一个处理器迁移到另一个处理器，并尝试保持进程在同一处理器上运行。这称为处理器亲和性。有两种类型的处理器亲和性：

1. 软亲和力—— 当操作系统有一个策略试图让进程在同一处理器上运行但不保证它会这样做时，这种情况称为软亲和力。
1. 硬关联 – 硬关联允许进程指定它可以运行的处理器子集。某些系统（例如 Linux）实现了软关联，但也提供了一些支持硬关联的系统调用，例如sched_setaffinity() 。

负载均衡

负载平衡是一种将工作负载均匀分布在 SMP 系统中所有处理器上的现象。仅在每个处理器都有自己有资格执行的专用进程队列的系统上才需要负载平衡。负载平衡是不必要的，因为一旦处理器空闲，它会立即从公共运行队列中提取可运行的进程。在 SMP（对称多处理）上，保持所有处理器之间的工作负载平衡非常重要，以充分利用拥有多个处理器的优势，否则一个或多个处理器将处于空闲状态，而其他处理器具有高工作负载以及等待处理的处理器列表。中央处理器。负载平衡有两种通用方法：********

1. 推送迁移 – 在推送迁移中，任务会定期检查每个处理器上的负载，如果发现不平衡，则会通过将进程从过载的处理器移动到空闲或不太繁忙的处理器来均匀分配每个处理器上的负载。
1. 拉动迁移 – 当空闲处理器从繁忙的处理器拉动等待任务以供其执行时，就会发生拉动迁移。

多核处理器 –

在多核处理器中，多个处理器核心放置在同一物理芯片上。每个核心都有一组寄存器来维护其架构状态，因此对操作系统来说就像一个单独的物理处理器。使用多核处理器的SMP 系统比每个处理器都有自己的物理芯片的系统速度更快，功耗更低。然而，多核处理器可能会使调度问题变得复杂。当处理器访问内存时，它会花费大量时间等待数据可用。这种情况称为MEMORY STALL。发生这种情况的原因有多种，例如高速缓存未命中，即访问不在高速缓存中的数据。在这种情况下，处理器可能会花费高达百分之五十的时间来等待内存中的数据可用。为了解决这个问题，最近的硬件设计已经实现了多线程处理器核心，其中两个或多个硬件线程被分配给每个核心。因此，如果一个线程在等待内存时停止，核心可以切换到另一个线程。有两种方法可以使处理器多线程化：

1. 粗粒度多线程—— 在粗粒度多线程中，一个线程在处理器上执行，直到发生内存停顿等长延迟事件，由于长延迟事件造成的延迟，处理器必须切换到另一个线程才能开始执行。线程之间切换的成本很高，因为必须先终止指令管道，然后其他线程才能开始在处理器核心上执行。一旦这个新线程开始执行，它就开始用它的指令填充管道。
1. 细粒度多线程—— 这种多线程主要在指令周期的边界以更精细的级别在线程之间切换。细粒度系统的架构设计包含线程切换的逻辑，因此线程之间切换的成本很小。

虚拟化和线程 –

在这种类型的多处理器调度中，即使是单个 CPU 系统也可以像多处理器系统一样运行。在具有虚拟化的系统中，虚拟化为系统上运行的每个虚拟机提供一个或多个虚拟CPU，然后在虚拟机之间调度物理CPU的使用。大多数虚拟化环境都有一个主机操作系统和许多来宾操作系统。主机操作系统创建并管理虚拟机。每个虚拟机都安装了一个来宾操作系统，并在该来宾中运行应用程序。每个来宾操作系统可以分配给特定的用例、应用程序或用户，包括分时甚至实时操作。任何假定在给定时间内取得一定进度的客户操作系统调度算法都会受到虚拟化的负面影响。分时操作系统尝试为每个时间片分配 100 毫秒，以便为用户提供合理的响应时间。给定的 100 毫秒时间片可能会花费远远超过 100 毫秒的虚拟 CPU 时间。根据系统的繁忙程度，时间片可能需要一秒或更长时间，这会导致登录该虚拟机的用户的响应时间非常差。这种调度分层的最终效果是，各个虚拟化操作系统仅接收可用 CPU 周期的一部分，即使它们认为自己正在接收所有周期并且正在调度所有这些周期。通常，一天中的时间虚拟机中的时钟不正确，因为计时器的触发时间不会比专用 CPU 上的计时器长。因此，虚拟化可能会抵消虚拟机内操作系统的良好调度算法的努力。参考 – 操作系统原理 – Galvin