Se a sua tarefa for o processo de apenas solicitação de tempo em uma CPU específica, não haverá alternância de contexto entre tarefas :-). Mas a CPU ainda pode ser interrompida, causando uma troca de contexto no kernel e de volta. E uma causa possível é o temporizador de preempção, verificando se existe outra tarefa para executar nesta CPU ...
O Linux pode evitar gerar interrupções temporárias de preempção na cpu quando não houver razão para fazê-lo. Veja CONFIG_NO_HZ_FULL . Para usar este recurso, ele deve ser ativado quando o kernel foi construído, e ele deve ser ativado usando uma opção de inicialização.
By default, no CPU will be an adaptive-ticks CPU. The "nohz_full=" boot parameter specifies the adaptive-ticks CPUs. For example, "nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks CPUs. Note that you are prohibited from marking all of the CPUs as adaptive-tick CPUs [...]
A LWN.net diz que "de acordo com Ingo Molnar, até 1% do tempo da CPU será economizado" para CPUs com adaptações. O documento do kernel diz que isso tem seis custos diferentes, e há também uma lista de "PROBLEMAS CONHECIDOS".
Esse ganho é relativamente pequeno, particularmente em comparação com os possíveis ganhos de taxa de transferência de redução da frequência de alternâncias de contexto entre várias tarefas, conforme mencionado nesta resposta: Como alterar o comprimento de fatias de tempo usadas pela CPU do Linux agendador?
Impressão pequena: estas medições são anteriores ao suporte a Specter, Meltdown, KPTI e x86 ASID :-(. E eu acho que elas também se aplicam a hardwares mais antigos. Pergunte a um especialista em kernel ou faça suas próprias medições sobre como o custo do contexto Mudanças mudaram na sua versão específica do kernel e no hardware ... PTI era amplamente suposto ser mitigado pelo ASID, exceto pelo software que invoca o kernel com muita freqüência, o principal exemplo sendo bancos de dados, mas eu não tenho uma boa compreensão. nos números.
A esperança de Molnar no patch RFC original era que, com o tempo, "provavelmente seria ativado pela maioria das distribuições Linux". Eu percebo que o Fedora 28 fornece um kernel padrão construído com NO_HZ_FULL support. O Debian 9, no entanto, não o faz.
Mais recentemente, o do Linux v4.17 remove um temporizador residual de 1 Hz do nohz_full CPUs . Eu imagino que o efeito na taxa de transferência é bem pequeno :-), mas eu tenho tentado seguir o status de NO_HZ_FULL benefits quando há múltiplos processos executáveis em uma CPU -
once we reach 0 Hz we can [then] remove the periodic tick assumption from nr_running>=2 as well, by essentially interrupting busy tasks only as frequently as the sched_latency constraints require us to do - once every 4-40 msecs, depending on nr_running.
Isso é um pouco confuso, já que a preempção já começou a usar uma marca separada e mais precisa em v2.6.25-rc1, cometer 8f4d37ec073c, "sched: escala de preempção de alta resolução" . Encontrado através deste comentário no mesmo artigo do LWN.net: link ).