Scheduler, timers e foreground boost Windows 11 25H2

Resposta curta

Estes valores controlam o Scheduler, a resolução de temporizadores, a distribuição de interrupções de relógio e o orçamento de DPC. Pelo nome isolado não é possível determinar todo o efeito: o Windows aplica máscaras de bits e normaliza os valores de entrada. Entradas diferentes podem definir o mesmo modo de funcionamento.

O que foi verificado

Verificou-se quais parâmetros do Scheduler e dos temporizadores o Kernel lê, como os valores são normalizados e quais campos de Win32PrioritySeparation respondem por quê.

Âmbito do estudo

Windows 11 25H2 build 26200.9168, Scheduler e timer paths do Kernel. Jogos e aplicações específicos não fizeram parte das medições.

Metodologia

Tabela-mestra de parâmetros do Kernel, observação de acessos em runtime ao Registry e verificação de campos de bits e da normalização de valores.

Parâmetros canónicos

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

Win32PrioritySeparation

O valor é composto por campos de bits. O Kernel determina separadamente o reforço da aplicação ativa (foreground boost), o tipo e a duração do quantum. Na build estudada, o valor inicial do Windows cliente é 0x02. Ao valor de entrada aplica-se a máscara 0x3F, pelo que entradas diferentes podem definir um mesmo modo do Scheduler.

A decomposição dos campos de bits bit a bit, a calculadora de valores equivalentes e as medições históricas de latência e FPS foram remetidas para um estudo separado «Win32PrioritySeparation: latência e FPS com carga total de CPU». O lado do utilizador da questão — escolha, efeito e reversão — é coberto pela página de configuração do BoosterX.

O parâmetro altera as regras de agendamento. Para avaliar o benefício numa tarefa concreta é necessário repetir o teste com carga de CPU e medir a latência; a configuração não garante uma aceleração universal.

Timer policy

GlobalTimerResolutionRequests e os parâmetros de temporizadores vizinhos são lidos de Session Manager\Kernel. Influenciam o âmbito de ação dos pedidos de resolução do temporizador, local ou de todo o sistema, e a distribuição das interrupções de relógio entre CPU. Nas plataformas suportadas, o agendamento separado dos relógios por CPU pode funcionar mesmo sem configuração forçada.

MaxDynamicTickDuration limita a duração do sono em idle sem relógios periódicos. A unidade de medida é 100 nanossegundos: 7500 significa 0.75 ms, e não 7.5 ms. O limite superior é ainda restringido pela resolução atual do temporizador. 0xFFFFFFFF remove o limite adicional.

DisableLowQosTimerResolution altera o limite para pedidos de resolução do temporizador de baixa prioridade. Uma resolução alta permanente não é, por si só, estabelecida.

Só vale a pena alterar as regras dos temporizadores para carga que realmente execute esses pedidos. Uma resolução alta permanente aumenta o número de interrupções do temporizador e o consumo de energia.

DPC budget e boost decay

DpcCumulativeSoftTimeout define o orçamento do tempo total de execução de DPC. Os seus limites de normalização, a relação com DpcWatchdogPeriod e os parâmetros vizinhos de DPC e os limites de worker foram analisados no estudo «DPC e Kernel Executive workers no Windows 11 25H2»; aqui não são recontados. ForceForegroundBoostDecay altera as regras de decaimento do reforço da aplicação ativa, e PassiveIntRealTimeWorkerPriority define a prioridade do thread especial de entrada/saída. Para PassiveIntRealTimeWorkerPriority, o código aceita 17..21; na ausência de entrada, é usado 16. O valor 18 é admissível e aumenta a prioridade.

Ao comparar, tenha em conta as unidades de medida e os limites dos intervalos. O Kernel normaliza valores não suportados, pelo que o número registado pode diferir do efetivamente aplicado.

Estes parâmetros dizem respeito ao agendamento do sistema e ao diagnóstico de drivers. Sem uma traço DPC/ISR não há fundamentos fiáveis para os alterar manualmente.

Resultados

• A leitura de todos os parâmetros da tabela foi confirmada em ntoskrnl.exe da build 26200.9168: Win32PrioritySeparation é lido na inicialização do Scheduler e na session initialization, os parâmetros dos temporizadores — nas fases de inicialização do Kernel.
• Foram confirmados os valores iniciais e a normalização: máscara 0x3F para Win32PrioritySeparation, intervalo 17..21 com recurso 16 para PassiveIntRealTimeWorkerPriority, unidade de 100 ns em MaxDynamicTickDuration.
• As próprias observações são qualitativas: neste estudo não foram medidos valores de latência, FPS ou carga em segundo plano.

O que foi confirmado

• Readers e normalização dos parâmetros em ntoskrnl.exe da build estudada.
• Valor inicial 0x02 para Win32PrioritySeparation e máscara 0x3F.
• O significado dos campos boost e quantum, unidades de MaxDynamicTickDuration.
• Normalização de PassiveIntRealTimeWorkerPriority até ao intervalo 17..21 com recurso 16.

O que não foi confirmado

• O impacto da alteração em FPS, latência ou capacidade de resposta.
• O benefício da alteração sem carga que realmente utilize temporizadores e DPC.

Conclusão prática

Mantenha os valores predefinidos. Altere os parâmetros apenas para carga que realmente execute os pedidos correspondentes e compare os resultados em execuções idênticas.

Restauro do estado

Reponha os valores predefinidos ou elimine as entradas opcionais. Os parâmetros do Kernel são aplicados no próximo arranque do Windows.

Limitações

As leituras na fase 0 do arranque podem não caber no intervalo de gravação do Procmon. O estudo confirma o código de leitura e a normalização na build 26200.9168. O número de execuções independentes de observação (arranques e traços) não está fixado nos dados do artigo, pelo que a repetibilidade das próprias observações dos readers não foi avaliada quantitativamente. Não foi estabelecido um impacto universal no desempenho ou na latência.

O estudo e as ferramentas utilizadas pertencem ao desenvolvedor do BoosterX, pelo que o desenvolvedor tem um interesse direto nos resultados. A metodologia e os limites de aplicabilidade estão descritos acima, e as conclusões podem ser verificadas pelos dados abertos e pelas fontes públicas enumeradas.

Fontes

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

Fontes públicas verificadas: 2026-09-02.

Histórico de alterações

• 2026-09-20: adicionado o aviso sobre conflito de interesses; datas de reviewed/modified harmonizadas.
• 2026-09-19: adicionadas a secção «Resultados», as referências cruzadas para os estudos Win32PrioritySeparation e dos parâmetros DPC/worker e a página de configuração do BoosterX; registada a ausência do número de execuções de observação.
• 2026-09-02: primeira publicação; confirmados os readers, a normalização e os campos de bits, adicionados os limites do benefício prático.