Scheduler, timer e foreground boost in Windows 11 25H2

Risposta breve

Questi valori controllano lo scheduler, la risoluzione dei timer, la distribuzione degli interrupt di clock e il budget DPC. Dal solo nome non è possibile determinare l’intero effetto: Windows applica maschere di bit e normalizza i valori di input. Voci diverse possono impostare lo stesso regime di funzionamento.

Cosa è stato verificato

È stato verificato quali parametri dello scheduler e dei timer legge il kernel, come vengono normalizzati i valori e quali campi di Win32PrioritySeparation rispondono a cosa.

Ambito della ricerca

Windows 11 25H2 build 26200.9168, scheduler e timer paths del kernel. Giochi e applicazioni specifici non sono stati inclusi nelle misurazioni.

Metodologia

Tabella master dei parametri del kernel, osservazione degli accessi runtime al Registry e verifica dei campi di bit e della normalizzazione dei valori.

Parametri canonici

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

Win32PrioritySeparation

Il valore è composto da campi di bit. Il kernel determina separatamente il potenziamento dell’applicazione attiva (foreground boost), il tipo e la durata del quanto. Nella build esaminata il valore iniziale di Windows client è 0x02. Al valore di input viene applicata la maschera 0x3F, quindi voci diverse possono impostare un solo regime dello scheduler.

L’analisi dei campi di bit bit per bit, il calcolatore dei valori equivalenti e le misurazioni storiche di latenza e FPS sono stati spostati in una ricerca separata «Win32PrioritySeparation: latenza e FPS a pieno carico della CPU». Il lato utente della questione — scelta, effetto e ripristino — è coperto dalla pagina di impostazione di BoosterX.

Il parametro modifica le regole di pianificazione. Per valutare l’utilità in un compito specifico occorre ripetere il test con carico della CPU e misurare la latenza; l’impostazione non garantisce un’accelerazione universale.

Timer policy

GlobalTimerResolutionRequests e i parametri dei timer adiacenti vengono letti da Session Manager\Kernel. Influenzano l’ambito di azione delle richieste di risoluzione del timer, locale o a livello di sistema, e la distribuzione degli interrupt di clock tra le CPU. Sulle piattaforme supportate la pianificazione separata dei clock per CPU può funzionare anche senza impostazione forzata.

MaxDynamicTickDuration limita la durata del sonno in inattività senza clock periodici. L’unità di misura è di 100 nanosecondi: 7500 significa 0.75 ms, non 7.5 ms. Il limite superiore è ulteriormente limitato dalla risoluzione corrente del timer. 0xFFFFFFFF rimuove il limite aggiuntivo.

DisableLowQosTimerResolution modifica il limite per le richieste a bassa priorità di risoluzione del timer. Una risoluzione costantemente elevata di per sé non viene impostata.

Vale la pena modificare le regole dei timer solo per un carico che esegue effettivamente tali richieste. Una risoluzione costantemente elevata aumenta il numero di interrupt del timer e il consumo di energia.

DPC budget e boost decay

DpcCumulativeSoftTimeout imposta il budget del tempo totale di esecuzione dei DPC. I suoi limiti di normalizzazione, il legame con DpcWatchdogPeriod e i parametri DPC adiacenti e i limiti dei worker sono analizzati nella ricerca «DPC e Kernel Executive workers in Windows 11 25H2»; qui non vengono ripetuti. ForceForegroundBoostDecay modifica le regole di decadimento del potenziamento dell’applicazione attiva, mentre PassiveIntRealTimeWorkerPriority imposta la priorità dello speciale thread di input/output. Per PassiveIntRealTimeWorkerPriority il codice accetta 17..21; in assenza della voce viene usato 16. Il valore 18 è ammesso e aumenta la priorità.

Nel confronto tenete conto delle unità di misura e dei limiti degli intervalli. Il kernel normalizza i valori non supportati, quindi il numero scritto può differire da quello effettivamente applicato.

Questi parametri riguardano la pianificazione di sistema e la diagnostica dei driver. Senza una traccia DPC/ISR non ci sono basi affidabili per modificarli manualmente.

Risultati

• La lettura di tutti i parametri della tabella è confermata in ntoskrnl.exe della build 26200.9168: Win32PrioritySeparation viene letto durante l’inizializzazione dello scheduler e la session initialization, i parametri dei timer — nelle fasi di inizializzazione del kernel.
• Sono confermati i valori iniziali e la normalizzazione: maschera 0x3F per Win32PrioritySeparation, intervallo 17..21 con fallback 16 per PassiveIntRealTimeWorkerPriority, unità di 100 ns per MaxDynamicTickDuration.
• Le osservazioni stesse sono qualitative: in questa ricerca non sono stati misurati valori di latenza, FPS o carico in background.

Cosa è confermato

• Readers e normalizzazione dei parametri in ntoskrnl.exe della build esaminata.
• Valore iniziale 0x02 per Win32PrioritySeparation e maschera 0x3F.
• Significato dei campi boost e quanti, unità di MaxDynamicTickDuration.
• Normalizzazione di PassiveIntRealTimeWorkerPriority fino all’intervallo 17..21 con fallback 16.

Cosa non è confermato

• L’influenza della modifica su FPS, latenza o reattività.
• L’utilità della modifica senza un carico che utilizzi effettivamente timer e DPC.

Conclusione pratica

Lasciate i valori predefiniti. Modificate i parametri solo per un carico che esegue effettivamente le richieste corrispondenti e confrontate i risultati in esecuzioni identiche.

Ripristino dello stato

Ripristinate i valori predefiniti o eliminate le voci non obbligatorie. I parametri del kernel vengono applicati al successivo avvio di Windows.

Limitazioni

Le letture nella fase 0 di avvio possono non rientrare nell’intervallo di registrazione di Procmon. La ricerca conferma il codice di lettura e la normalizzazione sulla build 26200.9168. Il numero di esecuzioni indipendenti dell’osservazione (avvii e tracce) nei dati dell’articolo non è registrato, quindi la ripetibilità delle osservazioni stesse dei reader non è stata valutata quantitativamente. Non è stata stabilita un’influenza universale su prestazioni o latenza.

La ricerca e gli strumenti utilizzati appartengono allo sviluppatore di BoosterX, quindi lo sviluppatore ha un interesse diretto nei risultati. La metodologia e i limiti di applicabilità sono descritti sopra, e le conclusioni possono essere verificate tramite i dati aperti e le fonti pubbliche elencate.

Fonti

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

Fonti pubbliche verificate: 2026-09-02.

Cronologia delle modifiche

• 2026-09-20: aggiunto il disclaimer sul conflitto di interessi; allineate le date reviewed/modified.
• 2026-09-19: aggiunte la sezione «Risultati», i riferimenti incrociati alle ricerche Win32PrioritySeparation e ai parametri DPC/worker e la pagina di impostazione di BoosterX; registrata l’assenza del numero di esecuzioni dell’osservazione.
• 2026-09-02: prima pubblicazione; confermati readers, normalizzazione e campi di bit, aggiunti i limiti dell’utilità pratica.