Scheduler, timers i foreground boost Windows 11 25H2

Krótka odpowiedź

Te wartości sterują harmonogramem, rozdzielczością timerów, rozkładem przerwań zegarowych i budżetem DPC. Po samej nazwie nie można określić całego efektu: Windows stosuje maski bitowe i normalizuje wartości wejściowe. Różne wpisy mogą ustawiać ten sam tryb pracy.

Co sprawdzano

Sprawdzano, które parametry harmonogramu i timerów odczytuje jądro, jak normalizowane są wartości i które pola Win32PrioritySeparation za co odpowiadają.

Zakres badania

Windows 11 25H2 build 26200.9168, scheduler i timer paths jądra. Konkretne gry i aplikacje nie wchodziły w pomiary.

Metodyka

Tabela główna parametrów jądra, obserwacja runtime-owych odwołań do Registry i weryfikacja pól bitowych oraz normalizacji wartości.

Parametry kanoniczne

Registry path	Value	Type	Default	Reader/timing
HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl	Win32PrioritySeparation	REG_DWORD	0x02	ntoskrnl.exe, następnie session initialization
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel	GlobalTimerResolutionRequests	REG_DWORD	0	kernel phase-0
ten sam path	MaxDynamicTickDuration	REG_DWORD	0xFFFFFFFF	dynamic tick duration limit
ten sam path	EnablePerCpuClockTickScheduling	REG_DWORD	0	phase-1 clock init
ten sam path	DisableLowQosTimerResolution	REG_DWORD	1	timer policy init
ten sam path	DpcCumulativeSoftTimeout	REG_DWORD	120000	DPC budget init
ten sam path	ForceForegroundBoostDecay	REG_DWORD	0	scheduler init
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\I/O System	PassiveIntRealTimeWorkerPriority	REG_DWORD	16	I/O worker init

Win32PrioritySeparation

Wartość składa się z pól bitowych. Jądro osobno określa wzmocnienie aktywnej aplikacji (foreground boost), typ i długość kwantu. W badanym buildzie wartość początkowa klienckiej wersji Windows wynosi 0x02. Do wartości wejściowej stosowana jest maska 0x3F, dlatego różne wpisy mogą ustawiać jeden tryb harmonogramu.

Rozbiór pól bitowych po bitach, kalkulator równoważnych wartości oraz historyczne pomiary opóźnienia i FPS zostały przeniesione do osobnego badania «Win32PrioritySeparation: opóźnienie i FPS przy pełnym obciążeniu CPU». Stronę użytkownika — wybór, efekt i przywracanie — zamyka strona ustawienia BoosterX.

Parametr zmienia reguły harmonogramowania. Aby ocenić korzyść w konkretnym zadaniu, trzeba powtórzyć test z obciążeniem CPU i zmierzyć opóźnienie; ustawienie nie gwarantuje uniwersalnego przyspieszenia.

Timer policy

GlobalTimerResolutionRequests i sąsiednie parametry timerów są odczytywane z Session Manager\Kernel. Wpływają na zakres działania żądań rozdzielczości timera, lokalny lub ogólnosystemowy, oraz na rozkład przerwań zegarowych między CPU. Na obsługiwanych platformach rozdzielne harmonogramowanie taktów po CPU może działać także bez wymuszonego ustawienia.

MaxDynamicTickDuration ogranicza długość snu w bezczynności bez okresowych taktów. Jednostka miary wynosi 100 nanosekund: 7500 oznacza 0.75 ms, a nie 7.5 ms. Górna granica jest dodatkowo ograniczana przez bieżącą rozdzielczość timera. 0xFFFFFFFF zdejmuje dodatkowy limit.

DisableLowQosTimerResolution zmienia ograniczenie dla żądań rozdzielczości timera o niskim priorytecie. Stała wysoka rozdzielczość sama w sobie przy tym nie jest ustawiana.

Reguły timerów warto zmieniać tylko dla obciążenia, które rzeczywiście wykonuje takie żądania. Stała wysoka rozdzielczość zwiększa liczbę przerwań timera i zużycie energii.

DPC budget i boost decay

DpcCumulativeSoftTimeout określa budżet łącznego czasu wykonywania DPC. Jego granice normalizacji, związek z DpcWatchdogPeriod oraz sąsiednie parametry DPC i limity workerów zostały omówione w badaniu «DPC i Kernel Executive workers w Windows 11 25H2»; tutaj nie są powtarzane. ForceForegroundBoostDecay zmienia reguły zanikania wzmocnienia aktywnej aplikacji, a PassiveIntRealTimeWorkerPriority określa priorytet specjalnego wątku roboczego wejścia-wyjścia. Dla PassiveIntRealTimeWorkerPriority kod przyjmuje 17..21; przy braku wpisu używane jest 16. Wartość 18 jest dopuszczalna i podnosi priorytet.

Przy porównaniu uwzględniaj jednostki miary i ograniczenia zakresów. Jądro normalizuje nieobsługiwane wartości, dlatego zapisana liczba może różnić się od faktycznie zastosowanej.

Te parametry dotyczą harmonogramowania systemowego i diagnostyki sterowników. Bez tracy DPC/ISR nie ma solidnych podstaw do ich ręcznej zmiany.

Wyniki

• Odczyt wszystkich parametrów tabeli potwierdzono w ntoskrnl.exe builda 26200.9168: Win32PrioritySeparation jest odczytywany przy inicjalizacji harmonogramu i session initialization, parametry timerów — na fazach inicjalizacji jądra.
• Potwierdzono wartości początkowe i normalizację: maska 0x3F dla Win32PrioritySeparation, zakres 17..21 z zapasowym 16 dla PassiveIntRealTimeWorkerPriority, jednostka 100 ns u MaxDynamicTickDuration.
• Same obserwacje są jakościowe: wartości opóźnienia, FPS ani obciążenia tła w tym badaniu nie mierzono.

Co potwierdzono

• Readers i normalizacja parametrów w ntoskrnl.exe badanego builda.
• Wartość początkowa 0x02 dla Win32PrioritySeparation i maska 0x3F.
• Znaczenie pól boost i kwantów, jednostki MaxDynamicTickDuration.
• Normalizacja PassiveIntRealTimeWorkerPriority do zakresu 17..21 przy zapasowym 16.

Czego nie potwierdzono

• Wpływu zmiany na FPS, opóźnienie lub responsywność.
• Korzyści ze zmiany bez obciążenia, które rzeczywiście używa timerów i DPC.

Wniosek praktyczny

Zostaw wartości domyślne. Zmieniaj parametry tylko dla obciążenia, które rzeczywiście wykonuje odpowiednie żądania, i porównuj wyniki w identycznych przebiegach.

Przywracanie stanu

Przywróć wartości domyślne lub usuń opcjonalne wpisy. Parametry jądra są stosowane przy następnym rozruchu Windows.

Ograniczenia

Odczyty na fazie 0 rozruchu mogą nie trafić w interwał zapisu Procmon. Badanie potwierdza kod odczytu i normalizację na buildzie 26200.9168. Liczba niezależnych przebiegów obserwacji (rozruchów i trac) nie została utrwalona w danych artykułu, dlatego powtarzalność samych obserwacji readers nie została oceniona ilościowo. Uniwersalny wpływ na wydajność lub opóźnienie nie został ustalony.

Badanie i użyte narzędzia należą do dewelopera BoosterX, dlatego deweloper ma bezpośredni interes w wynikach. Metodyka i granice stosowalności opisano powyżej, a wnioski można zweryfikować na podstawie otwartych danych i wymienionych publicznych źródeł.

Źródła

• Win32PrioritySeparation, Microsoft Learn, sprawdzono 2026-09-01.
• Timer resolution, Microsoft Learn, sprawdzono 2026-09-01.

Publiczne źródła sprawdzono: 2026-09-02.

Historia zmian

• 2026-09-20: dodano disclaimer o konflikcie interesów; uzgodniono daty reviewed/modified.
• 2026-09-19: dodano sekcję «Wyniki», odsyłacze do badań Win32PrioritySeparation i parametrów DPC/worker oraz stronę ustawienia BoosterX; utrwalono brak liczby przebiegów obserwacji.
• 2026-09-02: pierwsza publikacja; potwierdzono readers, normalizację i pola bitowe, dodano granice praktycznej korzyści.