Scheduler, timers e foreground boost no Windows 11 25H2

Resposta curta

Esses valores controlam o agendador, a resolução de timers, a distribuição de interrupções de clock 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. Registros diferentes podem definir o mesmo modo de operação.

O que foi verificado

Verificou-se quais parâmetros do agendador e de timers o kernel lê, como os valores são normalizados e quais campos de Win32PrioritySeparation respondem por quê.

Escopo da pesquisa

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

Metodologia

Tabela mestre 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
mesmo caminho	MaxDynamicTickDuration	REG_DWORD	0xFFFFFFFF	dynamic tick duration limit
mesmo caminho	EnablePerCpuClockTickScheduling	REG_DWORD	0	phase-1 clock init
mesmo caminho	DisableLowQosTimerResolution	REG_DWORD	1	timer policy init
mesmo caminho	DpcCumulativeSoftTimeout	REG_DWORD	120000	DPC budget init
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 do aplicativo ativo (foreground boost), o tipo e a duração do quantum. Na build pesquisada, o valor inicial do Windows cliente é 0x02. Ao valor de entrada aplica-se a máscara 0x3F, por isso registros diferentes podem definir um mesmo modo do agendador.

A análise dos campos de bits bit a bit, a calculadora de valores equivalentes e as medições históricas de latência e FPS foram movidas para uma pesquisa separada «Win32PrioritySeparation: latência e FPS sob carga total de CPU». O lado do usuário 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 em uma tarefa específica, é preciso repetir o teste com carga de CPU e medir a latência; a configuração não garante aceleração universal.

Timer policy

GlobalTimerResolutionRequests e os parâmetros de timers vizinhos são lidos de Session Manager\Kernel. Eles influenciam o escopo de ação das solicitações de resolução de timer, local ou em todo o sistema, e a distribuição das interrupções de clock entre as CPUs. Em plataformas compatíveis, o agendamento separado de clocks por CPU pode funcionar mesmo sem configuração forçada.

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

DisableLowQosTimerResolution altera a restrição para solicitações de resolução de timer de baixa prioridade. Uma resolução alta constante, por si só, não é estabelecida nesse caso.

Vale alterar as regras de timers apenas para carga que realmente executa tais solicitações. Resolução alta constante aumenta o número de interrupções de timer e o consumo de energia.

DPC budget e boost decay

DpcCumulativeSoftTimeout define o orçamento do tempo total de execução de DPC. Seus limites de normalização, a relação com DpcWatchdogPeriod e os parâmetros vizinhos de DPC e limites de worker são analisados na pesquisa «DPC e Kernel Executive workers no Windows 11 25H2»; aqui eles não são recontados. ForceForegroundBoostDecay altera as regras de decaimento do reforço do aplicativo ativo, e PassiveIntRealTimeWorkerPriority define a prioridade do thread especial de entrada e saída. Para PassiveIntRealTimeWorkerPriority, o código aceita 17..21; na ausência do registro, usa-se 16. O valor 18 é válido e eleva a prioridade.

Ao comparar, leve em conta as unidades de medida e as restrições de faixas. O kernel normaliza valores não suportados, por isso o número gravado pode diferir do efetivamente aplicado.

Esses parâmetros dizem respeito ao agendamento do sistema e ao diagnóstico de drivers. Sem uma trace de DPC/ISR, não há base confiável para alterá-los 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 agendador e no session initialization, os parâmetros de timers — nas fases de inicialização do kernel.
• Foram confirmados os valores iniciais e a normalização: máscara 0x3F para Win32PrioritySeparation, faixa 17..21 com reserva 16 para PassiveIntRealTimeWorkerPriority, unidade de 100 ns em MaxDynamicTickDuration.
• As próprias observações são qualitativas: valores de latência, FPS ou carga em segundo plano não foram medidos nesta pesquisa.

O que foi confirmado

• Readers e normalização dos parâmetros em ntoskrnl.exe da build pesquisada.
• Valor inicial 0x02 para Win32PrioritySeparation e máscara 0x3F.
• O sentido dos campos de boost e de quantum, unidades de MaxDynamicTickDuration.
• Normalização de PassiveIntRealTimeWorkerPriority até a faixa 17..21 com reserva 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 utiliza timers e DPC.

Conclusão prática

Mantenha os valores padrão. Altere os parâmetros apenas para carga que realmente executa as solicitações correspondentes, e compare os resultados em execuções idênticas.

Restauração do estado

Retorne os valores padrão ou exclua os registros opcionais. Os parâmetros do kernel são aplicados na próxima inicialização do Windows.

Limitações

Leituras na fase 0 da inicialização podem não entrar no intervalo de gravação do Procmon. A pesquisa confirma o código de leitura e a normalização na build 26200.9168. O número de execuções independentes de observação (inicializações e traces) não está registrado nos dados do artigo, por isso a repetibilidade das próprias observações dos readers não foi avaliada quantitativamente. Não foi estabelecido impacto universal sobre desempenho ou latência.

A pesquisa e as ferramentas utilizadas pertencem ao desenvolvedor do BoosterX, portanto o desenvolvedor tem 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 listadas.

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 disclaimer sobre conflito de interesses; datas de reviewed/modified alinhadas.
• 2026-09-19: adicionadas a seção «Resultados», referências cruzadas para as pesquisas Win32PrioritySeparation e de parâmetros DPC/worker e a página de configuração do BoosterX; registrada a ausência do número de execuções de observação.
• 2026-09-02: primeira publicação; confirmados readers, normalização e campos de bits, adicionados os limites do benefício prático.