调度延迟和唤醒延迟的区别

Question

调度延迟和唤醒延迟有什么区别

a) 选择要运行的进程是调度程序逻辑，这种延迟有多重要

b) 当一个进程被选中运行但它还没有运行时，是唤醒延迟恕我直言

有人可以帮助理解其中的区别吗？

Answer 1

调度延迟和唤醒延迟有什么区别？

这可能通过您的其他问题的答案来理解。

a) 选择要运行的进程是调度程序逻辑，这种延迟有多重要

假设您有两个任务，它们都想运行。一个需要 5 分钟，另一个需要 4 分钟的实际运行时间才能完成。如果你在他们之间打乒乓球大约 8 分钟，那么争吵应该会发生。每个切换可能需要 100 微秒。如果开关频率很高，那么开销可能会占很大比例。如果“滴答声”为 1mS，则切换开销为 10%（切换时间为 100uS），完成 4 分钟任务的工作大约需要 9 分钟，而第二个任务还剩 1 分钟。

有不同类型的调度延迟。一是上下文切换的时间。这可能涉及保存和恢复 CPU、浮点数和其他寄存器、更新 MMU（我的用户空间看到的内存）以及决定切换到哪个任务。缓存也可能需要根据情况刷新，并可能将状态迁移到不同的 CPU。这是我上面用作示例的 100uS 数字或切换时间。

另一个问题是重新安排的频率。这是另一个进程可以抢占几乎同等优先级的人的时间。这两个数字将相互竞争。即，100uS 可能适用于非常慢的 CPU，因此在上面的示例中，将 'ticks' 设置为 10mS 会将开销减少到仅 1%。但是，当重新安排频率降低时，重新安排的响应性会降低。

有些人在调度程序延迟中包含中断延迟。如果发生某些重要的硬件事件，您可能需要重新安排任务。还有许多不同的算法用于“挑选谁跑”。在所有情况下，“谁跑”可能没有正确答案，因此有许多不同的版本。 Linux 一般使用'completely fair scheduler' 或 CFS。

见：What is scheduler latency?
EETime article
LWN article

b) 当一个进程被选中运行但它还没有运行时，是 唤醒延迟。

我认为这就是我上面解释的“调度延迟”（但有些人可能会包含更多项目）。

同样，唤醒这个词可能有点含糊。有不同种类的“唤醒”。在现代电池供电系统上，当没有工作要做时，CPU 通常会进入低功耗状态。在这些情况下，唤醒时间可能会增加调度延迟。这是让 CPU（和内存等）从低功耗状态转为全速运行的额外时间。

---

我知道这些术语没有明确的定义，您需要查看作者可能使用它们的上下文。每种情况下的想法都相似，但具体细节可能不同。通常它取决于目标或用例。只处理调度程序代码的人可能会包括上下文时间和调度算法开销。中断延迟对他们来说是一个单独的问题。然而，对于一个具有更实时响应能力的固定嵌入式系统，中断延迟对整个系统很重要，人们可能会将它们混为一谈。

此外，许多人（认为他们）想要硬实时。这是某些任务最重要的地方。但是，通常较低优先级的任务可能即将等待 I/O。在这些情况下，给予较低优先级的任务可能会增加吞吐量或最小化完成工作案例的时间。桌面或服务器示例通常是这种情况。在吞吐量优化中，最好让任务等待“I/O”，因为这与硬件访问时间平行。