Como alterar a frequência de comutação de contexto do Linux?

Como é possível alterar a frequência de alternância de contexto do Linux (linaro, ubuntu, debian)?

Estou certo em trocar um sistema menos responsivo por um mais eficiente.

EDIT1: Eu tenho um processo principal que quero executar o mais rápido possível (ciclos máximos de clock por segundo), então pensei em reduzir a frequência da alternância de contexto (= aumentar a fatia do tempo). A questão é como fazê-lo, e haveria um efeito significativo. Posso calcular o custo da troca de contexto? Ou seja, posso estimar se aumentar o intervalo de tempo em dois, qual será meu ganho de desempenho em% para o processo principal de que me preocupo?

Se sua tarefa for o único processo que solicita tempo em uma CPU específica, não haverá alternância de contexto entre as tarefas :-). Mas a CPU ainda pode ser interrompida, causando uma troca de contexto no kernel e vice-versa. E uma causa possível é o temporizador de prevenção, verificando se há outra tarefa a ser executada nesta CPU ...

O Linux pode evitar a geração de interrupções de temporizador de preferência na CPU, quando não houver motivo para isso. Veja CONFIG_NO_HZ_FULL. Para usar esse recurso, ele deve ser ativado quando o kernel foi construído, e deve ser ativado usando uma opção de inicialização.

• https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
• https://lwn.net/Articles/549580/ "(quase) operação sem ticks completa na versão 3.10"

Por padrão, nenhuma CPU será uma CPU adaptativa. O parâmetro de inicialização "nohz_full =" especifica as CPUs do adaptive-ticks. Por exemplo, "nohz_full = 1,6-8" diz que as CPUs 1, 6, 7 e 8 devem ser CPUs adaptativas. Observe que você está proibido de marcar todas as CPUs como CPUs adaptáveis ​​[...]

O LWN.net diz que "de acordo com Ingo Molnar, até 1% do tempo da CPU será economizado" para as CPUs adaptativas. O documento do kernel diz que isso tem seis custos diferentes, e há também uma lista de "QUESTÕES CONHECIDAS".

Esse ganho é relativamente pequeno, principalmente se comparado aos ganhos potenciais de produtividade da redução da frequência das alternâncias de contexto entre várias tarefas, conforme mencionado nesta resposta: Como alterar a duração dos intervalos de tempo usados ​​pelo agendador de CPU do Linux?

Letras pequenas: essas medições anteriores ao Spectre, Meltdown, KPTI e x86 ASID suportam :-(. E acho que elas também se aplicam a hardware um pouco mais antigo. Pergunte a um especialista em kernel ou execute suas próprias medições sobre como o custo das alternâncias de contexto tem mudou na sua versão e hardware específicos do kernel ... PTI era amplamente mitigado pelo ASID, exceto pelo software que chama o kernel com muita frequência, o principal exemplo são os bancos de dados, mas não tenho uma boa compreensão dos números .

A esperança de Molnar no patch RFC original era que, com o tempo, "provavelmente será ativado pela maioria das distribuições Linux". Percebo que o Fedora 28 fornece um kernel padrão construído com NO_HZ_FULLsuporte. O Debian 9, no entanto, não.

Mais recentemente, o Linux v4.17 remove um tick de temporizador residual de 1 Hz das nohz_fullCPUs . Eu imagino que o efeito na taxa de transferência seja bem pequeno :-), mas eu tenho tentado seguir o status dos NO_HZ_FULLbenefícios quando existem vários processos executáveis ​​em uma CPU -

quando atingimos 0 Hz, podemos [então] remover a suposição periódica de ticks de nr_running> = 2, interrompendo essencialmente tarefas ocupadas apenas com a mesma frequência que as restrições sched_latency exigem que façamos - uma vez a cada 4-40 ms, dependendo do nr_running .

Isso é um pouco confuso, já que a preferência já começou a usar um tick separado e mais preciso na v2.6.25-rc1, commit 8f4d37ec073c, "sched: tick de preempção em alta resolução" . Encontrado por esse comentário no mesmo artigo do LWN.net: https://lwn.net/Articles/549754/ ).