CPU 排程器架構特定程式碼實現提示¶

Nick Piggin, 2005

上下文切換¶

1. 執行佇列鎖：預設情況下，`switch_to` 架構函式在持有執行佇列鎖的情況下被呼叫。通常這不是問題，除非 `switch_to` 可能需要獲取執行佇列鎖。這通常是由於上下文切換中的喚醒操作引起的。

要請求排程器在不持有執行佇列鎖的情況下呼叫 `switch_to`，您必須在一個頭檔案中 `#define __ARCH_WANT_UNLOCKED_CTXSW`（通常是在定義 `switch_to` 的標頭檔案中）。

在 CONFIG_SMP 的情況下，解鎖的上下文切換隻會給核心排程器實現帶來非常小的效能損失。

您的 cpu_idle 例程需要遵守以下規則

應該在空閒例程中停用搶佔。應該只啟用它來呼叫 schedule()，然後再次停用。
need_resched/TIF_NEED_RESCHED 只能被設定，直到執行的任務呼叫 schedule() 之前不會被清除。空閒執行緒只需要查詢 need_resched，永遠不能設定或清除它。
當 cpu_idle 發現 (need_resched() == 'true') 時，它應該呼叫 schedule()。否則，它不應該呼叫 schedule()。
只有當我們即將睡眠處理器直到下一次中斷時，才需要在檢查 need_resched 時停用中斷（這不會對 need_resched 提供任何保護，它會阻止丟失中斷）
4a. 這種型別的睡眠的常見問題似乎是
local_irq_disable(); if (!need_resched()) { local_irq_enable(); *** resched interrupt arrives here *** __asm__("sleep until next interrupt"); }
當 need_resched 變為高電平時，不需要中斷來喚醒它們的空閒例程可以設定 TIF_POLLING_NRFLAG。換句話說，它們必須定期輪詢 need_resched，儘管做一些後臺工作或進入低 CPU 優先順序是合理的。
- 5a. 如果設定了 TIF_POLLING_NRFLAG，並且我們確實決定進入中斷睡眠，則需要清除它，然後發出記憶體屏障（然後停用中斷測試 need_resched，如 3 中所述）。

arch/x86/kernel/process.c 包含輪詢和睡眠空閒函式的示例。

我發現的可能的 arch 問題（並嘗試修復或沒有修復）

sparc - 此時啟用 IRQ（？），將 local_irq_save 更改為 _disable。