Alterando o timeslice do sheduler de encadeamento do Windows

Question

Esta questão é sobre a possibilidade de ajustar o kernel do Windows em tempo real, como os oses, e formas de fazê-lo. É um tópico estreito bastante específico que requer um nível profundo de conhecimento - ou você sabe, ou não.

Estou na plataforma WS2016 x64 e posso definir a resolução do timer apenas para 500us (0,5ms), chamando a função NtSetTimerResolution() na biblioteca ntdll.dll . Eu acho que esse valor está ligado a timeslice sheduler.

No entanto, quero aumentá-lo para 100us . A medição pode envolver chamar NtDelayExecution() envolto em QueryPerformanceCounter() chamadas muitas vezes em loop e, em seguida, analisar estatísticas como jitter, desvio padrão, etc.

Como isso é suposto fazer? Existe algum registro / arquivo tweak, onde posso definir arbitrary windows sheduler timeslice?

PS. Algumas pessoas podem perguntar " Por que você precisa? ", ou "Não faça isso, está errado! ". Eu vejo esse tipo de pensamento e respondo com antecedência.

• Isso é apenas um experimento de software. É apenas para testar a possibilidade e os resultados físicos de fazê-lo.
• Estou ciente de que isso pode levar a problemas em potencial, como tempo extra de cpu desperdiçado apenas em comutadores de contexto, instabilidade do sistema, falta de responsabilidade, perda de dados e quaisquer problemas que possam causar. Aceito quaisquer consequências negativas de fazer isso com antecedência e assumir toda a responsabilidade. Mesmo que fumaça e faíscas saíssem da minha máquina:)
• Como pesquisando ou pesquisando aqui, de fato, fiz isso e não consegui encontrar informações úteis, porque esse tópico é bastante restrito, relacionado ao funcionamento dos shedulers do sistema operacional. E quase inútil fazer em qualquer máquina windows. Eu sei que não posso transformá-lo em tempo real. Esta pesquisa de site "timeslice sheduler" não dá resultado.

Answer 1

O intervalo de timeslice do agendador não é diretamente influenciado pela resolução do temporizador. Para a maioria dos processos nos SKUs do cliente, são 20 mseg; para um processo que possui a janela de primeiro plano, é de 60 ms. Esses valores são normalmente 120 ms em SKUs do servidor.

Estes valores são os mesmos, independentemente do que você faz com o NtSetTimerResolution. Seja qual for a resolução do temporizador, um número apropriado de interrupções do relógio do temporizador é contado antes que um intervalo de 20 ms seja detectado e o agendador diminua o contador "quantum" do encadeamento atual, etc.

Assim, se você conseguir melhorar a resolução do timer para 100 usec, isso não afetará o agendamento de threads. No entanto, ele criará sobrecarga adicional, o que com 5x o número anterior de chamadas para a rotina que verifica se algum temporizador expirou.

Não há registro ou outro ajuste para alterar isso.

Existe um hack de registro que pode ser usado para derrotar o "alongamento de timeslice" que ocorre em SKUs do cliente, ou para fazer um sistema de servidor se comportar como um cliente ou vice-versa, no que diz respeito ao tamanho do prazo. E às vezes (devido a um pequeno movimento de Thread- > Quantum que é feito quando um thread sai de uma espera) o timeslice pode ser um pouco mais curto do que "deveria" ter sido. Mas não há como definir o timeslice para menos de 20 ms, ou para nada além de um múltiplo de 20 ms, e não há muitos múltiplos diferentes disponíveis.

Observe que o intervalo de timeslice do agendador não tem efeito sobre a preempção. Quando a espera de um encadeamento é resolvida, se a prioridade do encadeamento for maior que a do encadeamento atualmente em execução no processador ideal do novo encadeamento, o último encadeamento será precedido imediatamente . Ele não consegue chegar ao final de seu intervalo de tempo antes de ser premiado. Timeslices são importantes somente quando há vários segmentos competindo na mesma prioridade.

Fonte: A maior parte disso está no Windows Internals de Solomon, Russinovich, et al .