Patches do Google para acelerar VMs Linux com excesso de comprometimento têm melhorias

Google acaba com mais um serviço e Domains irá para o Squarespace
google

Os engenheiros do Google têm trabalhado em patches do Linux para melhorar o desempenho da VM convidada quando o host encontra pressão de memória ou sobrecarrega muitos convidados. Assim, os patches do Google para acelerar VMs Linux com excesso de comprometimento têm melhorias

Patches semelhantes já são usados no Chrome OS e o Google tem trabalhado para atualizar a funcionalidade no kernel Linux principal e agora forneceu alguns resultados de benchmark de referência.A intenção dos patches é fornecer um caminho rápido para limpar o bit acessado sem obter o bloqueio KVM MMU. 

Patches do Google para acelerar VMs Linux com excesso de comprometimento têm melhorias

Após os patches v2 em maio, alguns novos resultados de desempenho foram publicados na lista de discussão do kernel para destacar os benefícios. Yu Zhao, do Google, observou algumas acelerações bastante significativas dentro das VMs ao lidar com hosts supercomprometidos.

Agora no ARM64 está consumindo 12% menos tempo ao classificar quatro bilhões de inteiros aleatórios vinte vezes como um teste de estresse. Memcached no POWER9 alcançou 10% mais operações por segundo com esta série de patches. Por fim, para Multichase em x86 em 64 micro-VMs, obtivemos 6% mais amostras com esta série de patches.Pelo menos desses três benchmarks publicados até agora, esta série de patches continua bastante promissora.

Patches do Linux atualizados para estados ociosos do Sapphire Rapids C0.x

Embora a Intel tenha trabalhado no suporte Sapphire Rapids para Linux anos atrás e para outros componentes-chave como GCC e LLVM/Clang para fornecer uma boa experiência de lançamento com processadores escaláveis ??Xeon de 4ª geração, eles não tinham trabalhado antes com os novos estados ociosos do C0.x. 

Esses novos estados ociosos entre POLL e C1 permitem uma combinação de baixa latência e melhor economia de energia do que POLL.Os engenheiros da Intel estão trabalhando nos patches do Linux para esses estados ociosos C0.1 e C0.2 há alguns meses para ajudar na eficiência de energia dos novos processadores Sapphire Rapids. Este trabalho acompanha outros patches pendentes para ajudar a aumentar o desempenho da VM sob uso intenso de E/S.

Patches do Google para acelerar VMs Linux com excesso de comprometimento têm melhorias.

No sábado, a terceira iteração do suporte a estados ociosos do Sapphire Rapids C0.x foi publicada. A carta de apresentação do patch resume elegantemente o trabalho como:

Os estados ociosos reduzem o consumo de energia quando uma CPU não tem trabalho a fazer. O estado ocioso da CPU mais superficial é “POLL”. Tem a menor latência de ativação, mas economiza pouca energia. O próximo estado ocioso nas plataformas Intel é “C1”.

Tem latência mais alta, mas economiza mais energia do que “POLL”.Sapphire Rapids Xeons adiciona novos estados ociosos C0.1 e C0.2 que conceitualmente ficam entre “POLL” e “C1”.

Latência de ativação do POLL e consumo de energia entre “POLL” e “C1”.Em outras palavras, esperamos que todos, exceto os usuários mais sensíveis à latência, prefiram esse estado ocioso em vez do POLL.Este conjunto de patches permite o estado ocioso C0.2 suporte em Sapphire Rapids Xeon (mais tarde – SPR) O novo estado ocioso é adicionado entre POLL e C1.

Com esta terceira iteração, há algumas pequenas alterações técnicas, pois esse novo código funciona em direção ao kernel principal.

Com o teste da Intel dos novos patches, a energia CA caiu 13% e a energia da CPU RAPL caiu 18% ao comparar a variação percentual de POLL para C0.2. Enquanto isso, ter C0,2 também permitiu que a pontuação do Hackbench melhorasse em cerca de 4% para 4 grupos. 

Com os patches, o estado C0.2 também pode ser desativado, se desejado, por meio da opção do kernel “intel_idle.states_off=2”.Trabalho interessante e espero que este código chegue à linha principal em breve – potencialmente até para a v6.5 se tudo estiver bem nesta terceira versão dos patches. Por enquanto, o trabalho pode ser encontrado na lista linux-pm. Assim que for captado pela linha principal, terei certeza de executar alguns benchmarks.