Linux kernel 调度延迟和唤醒延迟之间的差异

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

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

b） 当一个进程被选中运行但它尚未运行时，唤醒延迟是否为IMHO

有人能帮助理解这种差异吗

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

这一点可以通过回答您的其他问题来理解

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

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

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

另一个问题是重新安排的频率。这就是另一个进程可以先发制人的时间。这两个数字将相互竞争。也就是说，100uS可能用于非常慢的CPU，因此在上面的示例中，将“滴答声”设置为10mS会将开销减少到1%。然而，当重调度频率降低时，重调度响应将降低

有些人在调度程序延迟中包含中断延迟。在发生某些重要硬件事件时，您可能需要重新安排任务。此外，还有许多不同的“选择谁运行”算法。在所有的案例中，对于“谁运行”可能没有正确的答案，因此有许多不同的版本。Linux通常使用or或CFS

请参阅：

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

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

同样地，唤醒一词可能有点模棱两可。有不同类型的“唤醒”。在现代电池供电的系统中，当没有工作要做时，CPU通常处于低功耗状态。在这些情况下，唤醒时间可能会增加调度延迟。这是使CPU（和内存等）从低功耗状态恢复到全速运行的额外时间

---

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

---

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

这些问题的来源是什么？它是来自教科书、内核实现还是其他什么？在RT测试中有一种叫做唤醒延迟的东西。我搞不懂它是否包括调度器延迟你的意思是？在这种情况下，由于设置了计时器，它们指的是任务“唤醒”。这只是中断+调度程序延迟。术语“唤醒”是RT Linux测试工具cyclictest使用的术语。由于cpufreq和其他东西，如wakelocks或其他Android化身，会有额外的延迟。有人可能也会称之为“唤醒延迟”。如果您参考wallyk的一些资料，这会对您的问题有所帮助。对于这个基准测试，它只关心Linux代码的相对更改对基准测试的影响。它对于比较其他操作系统可能没有用处。这正是LinuxRT开发人员想要的。