Scheduler, timers et foreground boost Windows 11 25H2

Réponse courte

Ces valeurs contrôlent le planificateur, l’autorisation des timers, la répartition des interruptions d’horloge et le budget DPC. Leur nom seul ne permet pas de déterminer l’effet complet : Windows applique des masques binaires et normalise les valeurs d’entrée. Des entrées différentes peuvent définir un même mode de fonctionnement.

Ce qui a été vérifié

Nous avons vérifié quels paramètres du planificateur et des timers sont lus par le noyau, comment les valeurs sont normalisées et quels champs de Win32PrioritySeparation correspondent à quoi.

Périmètre de l’étude

Windows 11 25H2 build 26200.9168, chemins du planificateur et des timers du noyau. Les jeux et applications spécifiques n’ont pas été inclus dans les mesures.

Méthodologie

Table maîtresse des paramètres du noyau, observation des accès runtime au Registry et vérification des champs binaires et de la normalisation des valeurs.

Paramètres canoniques

Registry path	Value	Type	Default	Reader/timing
HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl	Win32PrioritySeparation	REG_DWORD	0x02	ntoskrnl.exe, puis 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

La valeur est composée de champs binaires. Le noyau détermine séparément le renforcement de l’application active (foreground boost), le type et la durée du quantum. Dans la build étudiée, la valeur initiale de Windows client est 0x02. Un masque 0x3F est appliqué à la valeur d’entrée, c’est pourquoi des entrées différentes peuvent définir un même mode de planificateur.

L’analyse bit par bit des champs binaires, le calculateur de valeurs équivalentes et les mesures historiques de latence et de FPS sont traités dans une étude distincte « Win32PrioritySeparation : latence et FPS sous charge CPU complète ». Le côté utilisateur — choix, effet et retour en arrière — est couvert par la page de réglage BoosterX.

Le paramètre modifie les règles de planification. Pour évaluer son intérêt dans une tâche donnée, il faut répéter le test sous charge CPU et mesurer la latence ; le réglage ne garantit pas d’accélération universelle.

Timer policy

GlobalTimerResolutionRequests et les paramètres de timers voisins sont lus depuis Session Manager\Kernel. Ils influencent la portée des demandes d’autorisation de timer, locale ou à l’échelle du système, et la répartition des interruptions d’horloge entre les CPU. Sur les plateformes prises en charge, la planification séparée des cycles par CPU peut fonctionner sans réglage forcé.

MaxDynamicTickDuration limite la durée de sommeil en veille sans cycles périodiques. L’unité de mesure est de 100 nanosecondes : 7500 signifie 0.75 ms, et non 7.5 ms. La limite supérieure est en outre restreinte par la résolution actuelle du timer. 0xFFFFFFFF supprime la limite supplémentaire.

DisableLowQosTimerResolution modifie la limite pour les demandes d’autorisation de timer à faible priorité. Une résolution élevée permanente n’est pas établie pour autant.

Il ne faut modifier les règles des timers que pour une charge qui exécute réellement de telles demandes. Une résolution élevée permanente augmente le nombre d’interruptions de timer et la consommation d’énergie.

DPC budget et boost decay

DpcCumulativeSoftTimeout définit le budget du temps d’exécution total des DPC. Ses bornes de normalisation, son lien avec DpcWatchdogPeriod et les paramètres DPC et limites de workers voisins sont analysés dans l’étude « DPC et Kernel Executive workers dans Windows 11 25H2 » ; ils ne sont pas repris ici. ForceForegroundBoostDecay modifie les règles de décroissance du renforcement de l’application active, et PassiveIntRealTimeWorkerPriority définit la priorité du thread d’entrée-sortie spécial. Pour PassiveIntRealTimeWorkerPriority, le code accepte 17..21 ; en l’absence d’entrée, 16 est utilisé. La valeur 18 est admissible et augmente la priorité.

Lors de la comparaison, tenez compte des unités de mesure et des limites de plage. Le noyau normalise les valeurs non prises en charge, c’est pourquoi le nombre écrit peut différer de celui réellement appliqué.

Ces paramètres relèvent de la planification système et du diagnostic des pilotes. Sans trace DPC/ISR, il n’existe pas de base fiable pour les modifier manuellement.

Résultats

• La lecture de tous les paramètres du tableau est confirmée dans ntoskrnl.exe de la build 26200.9168 : Win32PrioritySeparation est lu lors de l’initialisation du planificateur et de la session initialization, les paramètres de timers — aux phases d’initialisation du noyau.
• Les valeurs initiales et la normalisation sont confirmées : masque 0x3F pour Win32PrioritySeparation, plage 17..21 avec repli 16 pour PassiveIntRealTimeWorkerPriority, unité de 100 ns pour MaxDynamicTickDuration.
• Les observations elles-mêmes sont qualitatives : aucune valeur de latence, de FPS ou de charge de fond n’a été mesurée dans cette étude.

Ce qui est confirmé

• Les readers et la normalisation des paramètres dans ntoskrnl.exe de la build étudiée.
• La valeur initiale 0x02 pour Win32PrioritySeparation et le masque 0x3F.
• La signification des champs boost et quantums, les unités de MaxDynamicTickDuration.
• La normalisation de PassiveIntRealTimeWorkerPriority vers la plage 17..21 avec repli 16.

Ce qui n’est pas confirmé

• L’influence d’une modification sur les FPS, la latence ou la réactivité.
• L’intérêt d’une modification sans charge qui utilise réellement les timers et les DPC.

Conclusion pratique

Laissez les valeurs par défaut. Ne modifiez les paramètres que pour une charge qui exécute réellement les demandes correspondantes, et comparez les résultats dans des exécutions identiques.

Restauration de l’état

Rétablissez les valeurs par défaut ou supprimez les entrées facultatives. Les paramètres du noyau sont appliqués au prochain démarrage de Windows.

Limites

Les lectures à la phase 0 du démarrage peuvent ne pas tomber dans l’intervalle d’enregistrement de Procmon. L’étude confirme le code de lecture et la normalisation sur la build 26200.9168. Le nombre d’exécutions indépendantes d’observation (démarrages et traces) n’est pas consigné dans les données de l’article, c’est pourquoi la répétabilité des observations des readers n’a pas été évaluée quantitativement. Aucune influence universelle sur les performances ou la latence n’est établie.

L’étude et les outils utilisés appartiennent au développeur de BoosterX, le développeur a donc un intérêt direct dans les résultats. La méthodologie et les limites d’applicabilité sont décrites ci-dessus, et les conclusions peuvent être vérifiées à partir des données ouvertes et des sources publiques listées.

Sources

• Win32PrioritySeparation, Microsoft Learn, vérifié le 2026-09-01.
• Timer resolution, Microsoft Learn, vérifié le 2026-09-01.

Sources publiques vérifiées : 2026-09-02.

Historique des modifications

• 2026-09-20 : ajout d’un avertissement sur le conflit d’intérêts ; dates reviewed/modified alignées.
• 2026-09-19 : ajout de la section « Résultats », de renvois vers les études Win32PrioritySeparation et des paramètres DPC/worker et de la page de réglage BoosterX ; consignation de l’absence du nombre d’exécutions d’observation.
• 2026-09-02 : première publication ; confirmation des readers, de la normalisation et des champs binaires, ajout des limites de l’intérêt pratique.