Windows 11 25H2 的排程器、計時器與前景加速
本頁內容
這些值控制排程器、計時器解析度、時鐘中斷分配以及 DPC 預算。單憑名稱無法判定完整效果：Windows 會套用位元遮罩並將輸入值正規化。不同的登錄值可能設定出相同的運作模式。
我們檢查了核心會讀取哪些排程器與計時器參數、值如何被正規化，以及 Win32PrioritySeparation 的各個欄位各自負責什麼。
Windows 11 25H2 build 26200.9168，核心的 scheduler 與 timer paths。具體的遊戲與應用程式並未納入測量。
核心參數的主表格、對 Registry 的 runtime 存取觀察，以及位元欄位與值正規化的檢查。
| Registry path | Value | Type | Default | Reader/timing |
|---|---|---|---|---|
HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl |
Win32PrioritySeparation |
REG_DWORD |
0x02 |
ntoskrnl.exe，然後是 session initialization |
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel |
GlobalTimerResolutionRequests |
REG_DWORD |
0 |
kernel phase-0 |
| 同一路徑 | MaxDynamicTickDuration |
REG_DWORD |
0xFFFFFFFF |
dynamic tick duration limit |
| 同一路徑 | EnablePerCpuClockTickScheduling |
REG_DWORD |
0 |
phase-1 clock init |
| 同一路徑 | DisableLowQosTimerResolution |
REG_DWORD |
1 |
timer policy init |
| 同一路徑 | DpcCumulativeSoftTimeout |
REG_DWORD |
120000 |
DPC budget init |
| 同一路徑 | ForceForegroundBoostDecay |
REG_DWORD |
0 |
scheduler init |
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\I/O System |
PassiveIntRealTimeWorkerPriority |
REG_DWORD |
16 |
I/O worker init |
Win32PrioritySeparation
Section titled “Win32PrioritySeparation”該值由位元欄位組成。核心會分別判定前景應用程式增強（foreground boost）、量子（quantum）的類型與長度。在所研究的組建中，用戶端 Windows 的初始值等於 0x02。輸入值會套用遮罩 0x3F，因此不同的登錄值可能設定出同一種排程器模式。
逐位元的位元欄位解析、等效值計算器，以及延遲與 FPS 的歷史測量，已移至另一份研究「Win32PrioritySeparation：CPU 滿載時的延遲與 FPS」。至於使用者層面的問題——選擇、效果與還原——則由 BoosterX 設定頁面涵蓋。
此參數會改變排程規則。若要評估其在特定任務中的效益，必須在 CPU 負載下重複測試並測量延遲；此設定不保證能帶來通用的加速。
Timer policy
Section titled “Timer policy”GlobalTimerResolutionRequests 與相鄰的計時器參數是從 Session Manager\Kernel 讀取。它們會影響計時器解析度要求的適用範圍——是區域性還是全系統——以及時鐘中斷在 CPU 之間的分配。在支援的平台上，依 CPU 分別排程時鐘即使沒有強制設定也可能運作。
MaxDynamicTickDuration 會限制閒置時在沒有週期性時鐘下的睡眠長度。單位為 100 奈秒：7500 代表 0.75 ms，而不是 7.5 ms。上限還會進一步受到目前計時器解析度的限制。0xFFFFFFFF 則會移除額外的上限。
DisableLowQosTimerResolution 會改變低優先順序計時器解析度要求的限制。不過，這本身並不會設定持續的高解析度。
只有在負載確實會發出這類要求時，才值得變更計時器規則。持續的高解析度會增加計時器中斷次數與能源消耗。
DPC budget 與 boost decay
Section titled “DPC budget 與 boost decay”DpcCumulativeSoftTimeout 設定 DPC 總執行時間的預算。其正規化邊界、與 DpcWatchdogPeriod 的關聯，以及相鄰的 DPC 參數與 worker 限制，已在研究「Windows 11 25H2 中的 DPC 與 Kernel Executive workers」中解析；此處不再重述。ForceForegroundBoostDecay 會改變前景應用程式增強衰減的規則，而 PassiveIntRealTimeWorkerPriority 則設定特殊輸入輸出工作執行緒的優先順序。對於 PassiveIntRealTimeWorkerPriority，程式碼接受 17..21；若沒有登錄值則使用 16。值 18 是允許的，且會提高優先順序。
比較時請留意測量單位與範圍限制。核心會將不支援的值正規化，因此寫入的數字可能與實際套用的不同。
這些參數屬於系統排程與驅動程式診斷。沒有 DPC/ISR 追蹤，就沒有可靠依據可手動變更它們。
- 表格中所有參數的讀取已在 build
26200.9168的ntoskrnl.exe中獲得確認：Win32PrioritySeparation會在排程器初始化與 session initialization 時讀取，計時器參數則在核心初始化階段讀取。 - 初始值與正規化已獲確認：
Win32PrioritySeparation的遮罩0x3F、PassiveIntRealTimeWorkerPriority的範圍17..21與備援值16、MaxDynamicTickDuration的 100 奈秒單位。 - 觀察本身是質性的：本研究並未測量延遲、FPS 或背景負載的數值。
已確認的事項
Section titled “已確認的事項”- 所研究組建之
ntoskrnl.exe中的 readers 與參數正規化。 Win32PrioritySeparation的初始值0x02與遮罩0x3F。- boost 與量子欄位的意義、
MaxDynamicTickDuration的單位。 PassiveIntRealTimeWorkerPriority正規化至範圍17..21並以16作為備援。
未確認的事項
Section titled “未確認的事項”- 變更對 FPS、延遲或回應性的影響。
- 在沒有確實使用計時器與 DPC 的負載下，變更所帶來的效益。
請保留預設值。只有在負載確實會發出相應要求時才變更參數，並在相同的測試條件下比較結果。
請還原預設值，或刪除非必要的登錄值。核心參數會在下次 Windows 開機時套用。
開機 phase 0 的讀取可能不會落在 Procmon 的記錄區間內。本研究在 build 26200.9168 上確認了讀取程式碼與正規化。文章中並未記錄獨立觀察執行（開機與追蹤）的次數，因此讀取觀察本身的再現性並未進行量化評估。對效能或延遲的通用影響尚未確立。
本研究與所使用的工具均屬於 BoosterX 開發者，因此開發者對結果有直接的利益關係。方法與適用範圍已於上文說明，結論可依公開資料與所列的公開來源加以驗證。
- Win32PrioritySeparation，Microsoft Learn，查核於 2026-09-01。
- Timer resolution，Microsoft Learn，查核於 2026-09-01。
公開來源查核於：2026-09-02。
- 2026-09-20： 新增利益衝突免責聲明；對齊 reviewed/modified 日期。
- 2026-09-19： 新增「結果」章節、對
Win32PrioritySeparation與 DPC/worker 參數研究的交叉連結，以及 BoosterX 設定頁面；記錄了觀察執行次數的缺失。 - 2026-09-02： 首次發佈；確認 readers、正規化與位元欄位，新增實務效益的界限。