A IBM está trabalhando em mais otimizações de uso de energia da CPU do Linux para cargas de trabalho sensíveis à latência

Confira !!


Os engenheiros da IBM têm trabalhado em melhorias na economia de energia do kernel Linux enquanto executam tarefas sensíveis à latência, mas ainda oferecem desempenho comparável. Seus próprios números para um kernel corrigido estão mostrando benefícios significativos de economia de energia em aproximadamente 20%.

A nova série de patches constrói trabalhos anteriores publicados pela IBM no fornecimento de um botão "latency_nice" por tarefa para dicas do planejador. Latency_nice pode ser usado para indicar os requisitos de latência de uma determinada tarefa, para que o planejador possa tomar melhores decisões. Com esse trabalho de latency_nice publicado nos últimos meses, entre os casos de uso mencionados, houve melhores decisões de frequência turbo / boost com base no agrupamento de tarefas com requisitos de latência semelhantes. Além disso, hipoteticamente o agendador não atribui tarefas de baixa latência a uma CPU que encontra cargas de trabalho baseadas no AVX-512, onde geralmente as frequências principais se tornam bastante limitadas.

Com os novos patches do Parth Shah da IBM está ocioso na presença de tarefas sensíveis à latência. Este trabalho trata de impedir que o governador inativo da CPU caia para níveis mais baixos de energia ao executar uma tarefa indicada por latency_nice com baixa latência.

Os patches propostos restringem a CPU que executa tarefas sensíveis à latência a entrar em qualquer estado inativo, a fim de evitar o impacto da latência de saída quando precisar acelerar novamente para um estado de energia mais alto.

As cargas de trabalho que mais se beneficiam com essas correções são de baixa latência, aquelas que geralmente seguem um padrão de suspensão por ativação, como bancos de dados, cargas de trabalho da GPU e outros aplicativos em tempo real. Dos números da IBM, houve uma melhoria de cerca de 20% na eficiência de energia para um benchmark do planejador e de cerca de 20% para um servidor PostgreSQL.

Vamos ver aonde esses patches ociosos de conexão levam, além de mais amplamente à implementação latency_nice e a quais outras otimizações se conectam para se beneficiar dela.


Fonte

Até a próxima !!