SCHED_FIFO 可以被 SCHED_DEADLINE 搶占嗎？
如手冊頁所述：
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.這是否意味著即使是rtprio 99 的執行緒也會被 SCHED_DEADLINE 執行緒搶占？那裡有點直接說明，但我有點困惑，因為我認為 rtprio 99 將是系統中的最高優先級（看門狗，遷移，posixcputimer …）。我很想知道標準核心和 rt_patched 核心的這一點。謝謝大家。
手冊頁是正確的。不難發現這一點。
/* * 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 這樣做！”的列表中。Peter稍後會明確說明這一點。
看門狗肯定比實時程序在更大的時間尺度上執行，並且截止日期調度將為它們留出時間稍後執行（見下文）。
具有諷刺意味的是，我正在努力尋找有關實時核心中計時器行為的資訊。有一個RT wiki提到了優先級，但沒有提到截止日期……請注意，該頁面最後一次編輯是 2008 年，並指定了一台具有 PIII 400 Mhz cpu 的測試機器。有趣的是，Peter 在最初的評論中沒有提到計時器。看起來確實鼓勵 RT 程序盡可能使用 clock_nanosleep() 。（顯然，這對於 CPUTIME 時鐘幾乎沒有效用，這可能就是您所指的）。
如果程序不超過其指定的最壞情況執行時間，期限調度程序就有可能保證滿足期限。優先級調度程序沒有這個特性。
維護者贊成這種保證，而不是讓它以是否存在 SCHED_FIFO 程序為條件。沒有保證的截止日期安排將是完全不同的野獸……無論這是否還有一些效用；我真的不知道。
Deadline 調度程序具有最大頻寬 - 這是由 Linux 調度程序強制執行的。原則上，應該可以查看截止期限調度程序的總頻寬以及最大執行週期，並確定對任何優先級調度程序的最壞情況影響。反過來則不然，因為 POSIX 調度類 SCHED_FIFO 沒有強制執行 WCET。
截止日期系統消除了靜態優先級。相反，每個正在執行的任務都提供一組三個調度參數：
- 截止日期 - 必須完成工作的時間。
- 執行期 - 必須執行工作的頻率。
- 最壞情況執行時間 (WCET) - 完成工作所需的最大 CPU 時間。
程序的“頻寬”要求——它需要多少 CPU 百分比——很容易計算出來，因此調度程序一開始就知道系統是否超額訂閱。調度程序可以（並且應該）拒絕接受需要比系統可用頻寬更多的任務。通過拒絕多餘的工作，調度程序將始終能夠在指定的期限內為每個程序提供必要的 CPU 時間。這種承諾讓實時開發人員很高興。