Linux 核心搶佔機制全解析：從非搶佔到即時核心的演進

前言

Linux 2.5.4 引入核心搶佔，標誌著 Linux 從傳統協作式核心邁向可搶佔核心，為即時系統、多媒體低延遲應用奠基。本文系統梳理使用者/核心搶佔差異、非搶佔核心特點、搶佔必要性、不可搶佔區域、preempt_count 計數器機制與搶佔觸發時機。

一、核心搶佔 vs 使用者搶佔

使用者搶佔檢查 need_resched 標誌；核心搶佔額外要求 preempt_count == 0。

二、非搶佔核心（2.5.4 前）特點

• 進程進入核心態後佔用 CPU 直到主動放棄（睡眠、schedule、退出）。
• 單 CPU 下極大簡化同步：核心代碼串列執行，無並發競爭，只需關中斷保護臨界區。
• 自願放棄 CPU 為預期行為，僅需在已知切換點處理並發。

三、為何需要核心搶佔？

1. 硬即時需求：硬體中斷喚醒即時進程後，必須在確定延遲內排程。非搶佔核心長系統調用可導致 100ms+ 延遲，不可接受。
2. 多媒體低延遲：音視頻處理對抖動敏感，核心搶佔大幅降低最壞情況延遲。

四、五大不可搶佔區域

核心搶佔雖可在「任意安全點」發生，但以下五種情況必須禁止搶佔：

五、preempt_count 計數器機制

• 儲存於 task_struct->preempt_count。
• 進入上述五區域任一 → preempt_count++（可重入，嵌套遞增）。
• 離開區域 → preempt_count--，歸零時檢查 need_resched，若置位則呼叫 schedule()。
• 宏操作：preempt_disable()/preempt_enable()、spin_lock()/spin_unlock() 內部自動增減。

六、核心搶佔具體觸發點

1. 中斷返回核心態：檢查 need_resched && preempt_count==0 → schedule()。
2. 解鎖 / 啟用軟中斷：spin_unlock()、local_bh_enable() 遞減計數器歸零時檢查觸發。
3. 顯式 schedule()：代碼明確知道可安全搶佔。
4. 阻塞（睡眠、等待鎖等）：同樣導致 schedule()。

七、即時核心（PREEMPT_RT）補充

• 將絕大多數 spinlock 替換為 rtmutex（可搶佔互斥鎖），中斷執行緒化（IRQ threads），消除不可搶佔區域。
• 代價：鎖開銷增加、上下文切換頻繁，但實現硬即時（最壞延遲可控在微秒級）。

總結

核心搶佔以 preempt_count 為守門員，精準劃定「可搶佔」與「不可搶佔」邊界。理解五大禁區與計數器增減邏輯，是編寫高效核心模組、診斷延遲抖動、移植 PREEMPT_RT 的基石。