Seria razoável supor que para o kernel seria muito fácil não fazer nada - mas não é. Na conferência
Kernel Recipes 2018 ,
Rafael Vysotsky falou sobre o que os processadores fazem, quando não têm nada para fazer, como o kernel o processa, qual é sua estratégia atual e como seu trabalho recente no
ciclo inativo melhorou a situação energética de sistemas que não fazem nada. .
O ciclo de inatividade, um dos subsistemas de kernel suportados pelo Vysotsky, controla o que a CPU faz quando não precisa executar nenhum processo. Vysotsky forneceu todas as definições com muita precisão: uma CPU é uma entidade que pode receber instruções da memória e executá-las simultaneamente com outras entidades no mesmo sistema que lidam com a mesma coisa. No sistema mais simples de processador único com um núcleo, esse núcleo é a CPU. Se o processador tiver vários núcleos, cada um deles será uma CPU. Se cada um dos núcleos tiver várias interfaces para executar instruções simultaneamente - a Intel chama esse sistema de "
hyperthreading " -, cada um desses threads será uma CPU.
A CPU está ociosa quando não possui tarefas a serem executadas. Ou, mais precisamente, o kernel do Linux possui várias classes internas para envio, uma das quais é uma classe inativa especial. Se não houver tarefas nesta CPU em nenhuma das classes, exceto na classe de inatividade, a CPU será considerada inativa. Se o equipamento não permitir isso, a CPU terá que executar instruções inúteis até que o trabalho real aconteça. No entanto, esse é um uso extremamente ineficiente de eletricidade, e é por isso que a maioria dos processadores suporta vários estados de baixa energia nos quais o núcleo os transfere até que sejam necessários para realizar um trabalho útil.
Você não pode simplesmente entrar ou sair de um estado de inação. Leva tempo para entrar e sair e, além disso, quando você entra nesse estado, o consumo de energia do estado atual aumenta um pouco e, quando você sai, consome o estado em que o processador entra. E, quanto mais profundo o estado de inatividade, menos energia o processador consome, o custo de entrar e sair desses estados aumenta. Isso significa que, no caso de curtos períodos de inatividade, o melhor uso dos recursos do computador será uma inação superficial; por períodos mais longos, o custo de mudança para um estado de inação mais profundo será justificado por um aumento na quantidade de energia economizada. Portanto, é do interesse do kernel prever por quanto tempo o processador ficará ocioso antes de decidir a profundidade do estado de inatividade necessário. Essa é a tarefa do ciclo de inação.
Nesse ciclo, o planejador percebe que a CPU está ociosa, pois não possui nenhuma tarefa que possa ser atribuída a ela. Em seguida, o planejador chama o regulador, que tenta fornecer a melhor previsão do estado de inação apropriado, no qual você pode inserir. Agora no kernel existem dois controles, menu e escada. Eles são usados em casos diferentes, mas ambos tentam fazer aproximadamente a mesma coisa: monitorar o estado do sistema quando a CPU entra em estado inativo e o tempo gasto em inatividade. Isso é feito para prever por quanto tempo a CPU entrará em um estado de inatividade e, portanto, qual o estado mais adequado para essa situação.
Este trabalho é especialmente complicado pelo timer do agendador da CPU. O agendador inicia esse cronômetro para dividir o tempo de acesso à CPU: se várias tarefas precisam ser executadas em um processador, cada uma delas pode ser realizada apenas um pouco e, em seguida, adiada periodicamente em favor de outra tarefa. Esse cronômetro não precisa ser executado em uma CPU ociosa, pois não há tarefas entre as quais a CPU precise ser dividida. Além disso, se o timer puder executar em uma CPU ociosa, isso impedirá que o controlador selecione estados ociosos profundos, limitando os intervalos durante os quais a CPU está ociosa. Portanto, em kernels até 4,16, o agendador desligou o timer antes de chamar o regulador. Quando a CPU acordou com a interrupção, o planejador decidiu se havia alguma tarefa necessária para a execução e, se houver, reiniciou o cronômetro.
Se o controlador predizer um longo período de inatividade, e esse período realmente for longo, o controlador "vencerá": a CPU entra em um estado de profunda inatividade e a energia é economizada. Mas se o regulador prevê um longo período de inatividade, e esse período acaba sendo curto, então o regulador "perde", pois o custo de entrar em profunda inação não compensa economizando energia por um curto período de inatividade. Pior ainda, quando o regulador prevê um curto tempo de inatividade, ele “perde” independentemente do tempo de inatividade: se o período acabou sendo longo, ele perdeu a oportunidade de economizar e, se curto, os custos de parar e reiniciar o temporizador foram desperdiçados. Ou, em outras palavras, como os recursos são gastos em parar e iniciar o cronômetro, não faz sentido pará-lo quando o controlador prevê um curto tempo de inatividade.
Vysotsky decidiu tentar alterar a operação do regulador, mas chegou à conclusão de que o principal problema é que o temporizador é parado antes que o regulador seja chamado, ou seja, antes que o estado de inatividade recomendado seja conhecido. Ele retornou um ciclo inativo no kernel 4.17 para que a decisão de interromper o cronômetro fosse tomada depois que o regulador fez sua recomendação. Se ele previu um longo tempo de inatividade, o temporizador para para não ativar a CPU antes do tempo. Se o tempo de inatividade for considerado curto, o cronômetro será deixado para evitar o desperdício de recursos em desligamentos. Isso significa que o temporizador também desempenha uma função de segurança, despertando a CPU, se o tempo de inatividade for mais longo do que o previsto, e dando ao regulador uma segunda chance para a decisão certa.
Quando uma CPU inativa é ativada por uma interrupção, seja um cronômetro imparável ou outro evento, o agendador toma uma decisão imediatamente sobre a disponibilidade do trabalho. Se houver trabalho, o temporizador reinicia conforme necessário. Caso contrário, o controlador é chamado. Como isso significa que agora o regulador pode ser chamado quando o temporizador está funcionando e quando não está funcionando, o regulador deve ser chamado para levar isso em consideração.
Tendo estudado a tabela de vitórias e derrotas, Vysotsky acredita que suas mudanças melhorarão o cenário. No caso de prever um longo período de inatividade, o temporizador ainda para, então nada muda aqui; vencemos se o tempo de inatividade for longo e perdemos se for curto. Mas se for previsto um curto período de inatividade, vencemos: se o período realmente for curto, economizaremos a interrupção e o início do cronômetro e, se for longo, um cronômetro ininterrupto nos acordará e nos dará a oportunidade de fazer outra previsão.
Como a teoria dos jogos não pode servir como um substituto completo para a situação real, Vysotsky testou essa abordagem em muitos sistemas. O gráfico acima é típico para todos os sistemas testados; mostra a dependência de tempo do consumo de energia em um sistema inativo. A linha verde é o antigo ciclo de inação, a linha vermelha é a nova. De acordo com o novo esquema, menos energia é consumida e, além disso, é mais previsível. Nem todas as CPUs testadas tiveram uma lacuna tão grande entre as linhas, no entanto, todas elas mostraram uma linha vermelha plana sob verde irregular. Como Vysotsky disse, é menos provável que esse novo esquema preveja curtos períodos de inatividade, mas, com mais freqüência, acaba sendo certo quanto à sua curta duração.
Respondendo a uma pergunta da platéia, Vysotsky disse que este trabalho depende da arquitetura. Em particular, os processadores da Intel se beneficiarão disso, uma vez que eles têm uma variedade bastante grande de estados de inatividade, dos quais o regulador pode escolher aquele que lhe dará a melhor chance de sucesso se a previsão estiver correta; mas os processadores ARM também se beneficiarão com o novo circuito.
Uma queda de 20% no consumo de energia quando ociosa pode parecer uma conquista insignificante, mas na verdade não é. Qualquer sistema que queira lidar razoavelmente bem com as cargas de pico deve ter uma reserva de energia no modo normal, que se manifestará durante a inatividade. O gráfico acima mostra o uso do processador durante o ano no meu servidor, que trata de correio, transferência de arquivos, VPN, NTP, etc. Amarelo significa tempo simples. Economizar 20% dessa energia seria apreciado pelo meu provedor e, para o planeta, seria melhor.