正如手册页中所述：
A SCHED_FIFO thread runs until either it is blocked by an I/O
request, it is preempted by a higher priority thread, or it calls
sched_yield(2).
来自同一来源：
SCHED_DEADLINE threads are the
highest priority (user controllable) threads in the system; if any
SCHED_DEADLINE thread is runnable, it will preempt any thread
scheduled under one of the other policies.
这是否意味着即使线程rtprio99 会被SCHED_DEADLINE线程抢占吗？它有点直接说明在那里，但我有点困惑，因为我认为 rtprio 99 将是系统中的最高优先级（看门狗，迁移，posixcputimer ...）。我很想知道标准内核和 rt_patched 内核的这一点。感谢大家。
答案1
手册页是正确的。对此的证实应该不难。
/* * SCHED_DEADLINE tasks has negative priorities, reflecting * the fact that any of them has higher prio than RT and * NORMAL/BATCH tasks. */ #define MAX_DL_PRIO 0
这是 Linux 调度程序的维护者选择的方法。我在下面引用了 LWN 的解释，尽管您应该渴望阅读所有与您的兴趣相关的 LWN 文章的全文。由于这些内容的长度有限，我不能保证它们能解决您可能遇到的每个具体困惑。 https://lwn.net/Articles/356576/
不过，Peter Zijlstra 认为截止日期调度应该以最高优先级运行；否则无法确保按时完成任务。
我有点困惑，因为我认为 rtprio 99 将是系统中的最高优先级（看门狗、迁移、posixcputimer...）
LWN 链接到 Peter 的初步审查，其中提到了这一点。
唯一需要绝对最高优先级的两个任务是 kstopmachine 和 migrate，因此这些任务需要提升到 EDF 之上，其余的并不重要:-)
我不确切知道这种情况下的迁移是什么，但 LWN 文章确实指出 SMP 实时是一个挑战。
stopmachine 在列表中表示“所以不要为 RT 这样做！”，出于这个原因。彼得明确指出了这一点稍后的。
看门狗肯定比实时进程在更长的时间尺度上运行，并且截止期限调度将为它们留出时间以便稍后运行（见下文）。
具有讽刺意味的是，我正在努力寻找有关实时内核中计时器行为的信息。有一个RT维基其中提到了优先级，但没有提到最后期限...请注意，该页面的最后编辑时间是 2008 年，并指定了一台带有 PIII 400 Mhz cpu 的测试机器。同样有趣的是，彼得在最初的评论中没有提到计时器。看起来确实鼓励 RT 进程在可能的情况下使用clock_nanosleep()。 （显然，这对 CPUTIME 时钟几乎没有任何用处，这可能就是您所指的）。
只要进程不超过其指定的最坏情况执行时间，截止日期调度程序就有可能保证满足截止日期。优先级调度器没有这个功能。
维护者赞成这种保证，而不是以 SCHED_FIFO 进程是否存在为条件。没有保证的最后期限安排将是相当不同的野兽......无论这是否会留下一些效用；我真的不知道。
截止日期调度进程具有最大带宽 - 这是由 Linux 调度程序强制执行的。原则上，应该可以查看截止时间调度进程的总带宽以及最大执行周期，并确定对任何优先级调度进程的最坏情况影响。反之则不然，因为 POSIX 调度类 SCHED_FIFO 没有强制实施 WCET。
截止期限系统不再使用静态优先级。相反，每个正在运行的任务都提供了一组三个调度参数：
- 截止日期——工作必须完成的时间。
- 执行周期 - 工作必须执行的频率。
- 最坏情况执行时间 (WCET) - 完成工作所需的最大 CPU 时间。
进程的“带宽”要求（它需要 CPU 的百分比）很容易计算，因此调度程序一开始就知道系统是否超额订阅。调度程序可以（并且应该）拒绝接受需要比系统可用带宽更多的带宽的任务。通过拒绝多余的工作，调度程序将始终能够在指定的期限内为每个进程提供必要的 CPU 时间。这种承诺让实时开发人员感到高兴。