Um Patch da Huawei quer Ativar o Boost de CPU por padrão no ACPI CPPC do Linux: O que muda para os Servidores ARM64?

 

Patch da Huawei quer ativar o boost de CPU por padrão no driver ACPI CPPC do Linux em servidores ARM64; entenda os impactos, as polêmicas e as alternativas para os admins de TIC.

Um patch da Huawei propõe ativar o modo boost por padrão no driver genérico ACPI Collaborative Processor Performance Control (CPPC) CPUFreq do Linux, muito usado em servidores ARM64. 

Hoje, quando a CPU suporta boost, ele fica desativado por padrão e exige um  ajuste manual via sysfs. 

A mudança promete facilitar o desempenho máximo, mas levanta dúvidas sobre consumo, térmica e throttling.

Para aqueles que usam o driver genérico ACPI Collaborative Processor Performance Control (CPPC) CPUFreq, como em várias plataformas de servidor ARM64 Linux, se as CPUs suportam um modo "boost", ele fica desativado por padrão. 

Mas um patch da Huawei agora busca ativar o modo boost de CPU por padrão no Linux. O modo boost para processadores em que o nível de desempenho mais alto é maior que o nível de desempenho nominal foi desativado por padrão com o driver ACPI CPPC e exigia definir a opção "boost" via sysfs. 

Especialmente para plataformas de servidor Linux, isso pode ser considerado um padrão ruim, onde o potencial máximo de desempenho normalmente é desejado.

Este patch propõe ativar o boost por padrão para evitar a necessidade de o espaço do usuário defini-lo manualmente.

O engenheiro da Arm e desenvolvedor Linux Christian Loehle respondeu ao patch com:

"Eu frequentemente me pergunto se deveríamos manter o boost de qualquer forma; o envelope de energia e térmico no silício hoje em dia é complexo o suficiente para que isso tenha pouco significado, não garante de forma alguma que não haverá throttling ou que você receberá o desempenho solicitado. 

O usuário (ciente do silício) sempre pode definir individualmente os tetos de modo que 'funcione' para sua combinação de plataforma/carga de trabalho/ambiente via scaling_max_freq.

Como o commit 54e74df5d76d também foi introduzido pela Huawei, eu ficaria curioso sobre o uso lá, AFAICS ter uma plataforma com NOMINAL_PERF != HIGHEST_PERF é apenas uma dor de cabeça adicional no Linux por enquanto?"

Então veremos o que acontece com o patch ou, em última análise, como o código ACPI CPPC do Linux será limpo para ajudar com os servidores ARM64 modernos.

O que é o ACPI CPPC e por que ele importa?

O ACPI CPPC é uma interface padronizada para o sistema operacional colaborar com o hardware na gestão de desempenho e energia. Em vez de o Linux “adivinhar” frequências, ele conversa com o firmware e recebe faixas de performance. 

Em servidores ARM64 modernos, isso é especialmente relevante porque a eficiência energética e o desempenho por watt definem custos de datacenter.

O driver CPUFreq usa essas informações para escalar a frequência. Quando existe boost, o processador pode ultrapassar o nível nominal por curtos períodos. É útil para cargas interativas, bancos de dados e picos de tráfego. 

Porém, em servidores, o ganho precisa ser equilibrado com refrigeração, densidade de racks e SLA.

O que o patch da Huawei propõe?

O patch quer que o boost seja habilitado por padrão quando a plataforma expõe NOMINAL_PERF diferente de HIGHEST_PERF. Hoje, o administrador precisa escrever em sysfs para ativar. 

A proposta elimina esse passo manual. Para quem gerencia frotas grandes, isso reduz configuração repetitiva e evita que máquinas fiquem abaixo do potencial máximo.

A justificativa é prática: se o hardware foi comprado com modo boost, faz sentido usá-lo por padrão. Em ambientes de nuvem, HPC e borda, cada ponto de desempenho conta. A mudança também alinha o Linux a uma expectativa comum: “se a CPU suporta, o sistema deveria aproveitar”.

Produto Recomendado

Você que vive no terminal, respira software livre e defende o Fedora Linux de coração sabe: a mesa de trabalho também é um reflexo da sua identidade.

A Caneca Geek Fedora Linux foi feita para quem não aceita menos que qualidade e estilo. Com design exclusivo inspirado na distribuição que conquistou milhões de desenvolvedores pelo mundo, ela é o companheiro perfeito para o café da manhã, o chá da tarde ou aquela pausa estratégica antes do próximo commit.

Por que você vai amar:

☕ Cerâmica premium de 325ml – resistente e durável

🐧 Design exclusivo Fedora Linux – para os verdadeiros fãs

🎨 Impressão de alta qualidade – não desbota com o tempo

💻 Ideal para devs, sysadmins, analistas e entusiastas de Linux

🎁 Presente perfeito para quem é apaixonado por tecnologia e open source

Oferta especial: Frete grátis para todo o Brasil + embalagem reforçada para chegar perfeita na sua casa.

Estoque limitado! Garanta a sua antes que acabe.

👉 Clique em Comprar Agora e leve a Caneca Geek Fedora Linux para a sua mesa. https://link.amazon/B0g6ZmiW2

Eu ganho uma comissão quando você faz uma compra.

A crítica de Christian Loehle

Christian Loehle, engenheiro da Arm e desenvolvedor Linux, questiona se o boost ainda faz sentido. Para ele, o envelope de energia e térmico do silício atual é tão complexo que o boost não garante ausência de throttling nem entrega real do desempenho solicitado. 

O usuário ciente do hardware pode definir tetos via scaling_max_freq conforme plataforma, carga e ambiente.

Ele também levanta um ponto sobre o commit 54e74df5d76d, introduzido pela Huawei. Ter uma plataforma com NOMINAL_PERF != HIGHEST_PERF, segundo ele, pode ser apenas uma dor de cabeça adicional no Linux. A fala não é contra desempenho, mas contra padrões que prometem mais do que o sistema consegue sustentar.

Impactos para servidores ARM64

Para servidores ARM64, o boost pode melhorar latência de resposta e throughput em picos. Mas também aumenta consumo, temperatura e risco de throttling. Em datacenters com refrigeração limitada, ativar tudo por padrão pode mascarar problemas de capacidade. O ideal é medir.

Além disso, ferramentas de observabilidade precisam acompanhar frequência, instruções por ciclo, temperatura e potência. Sem isso, o administrador não sabe se o boost está ajudando ou apenas elevando o custo energético. 

A decisão deve ser baseada em carga real, não em promessa de marketing.

Prós e contras

• Prós: menos ajuste manual; melhor desempenho em picos; alinhamento com hardware que já suporta boost; simplificação para frotas grandes. 

• Contras: maior consumo; mais calor; possível throttling; comportamento variável entre plataformas; necessidade de validação por workload.

Como administradores podem agir

Verifique se a CPU expõe NOMINAL_PERF e HIGHEST_PERF.

Teste com boost desligado e ligado.

• Meça latência, throughput, potência e temperatura.

• Ajuste scaling_max_freq se necessário.

• Documente a configuração por tipo de servidor.

• Monitore throttling e erros de firmware.

• Consulte o Linux Kernel Archives e a ACPI Specification.

• Conheça o ecossistema ARM e as soluções Huawei.

Checklist para copiar e colar

[ ] Confirmar suporte a ACPI CPPC no kernel.

[ ] Verificar se a CPU tem modo boost.

[ ] Medir desempenho com boost desativado.

[ ] Medir desempenho com boost ativado.

[ ] Comparar consumo e temperatura.

[ ] Testar carga real do servidor.

[ ] Ajustar scaling_max_freq se necessário.

[ ] Documentar configuração por frota.

[ ] Monitorar throttling em produção.

[ ] Revisar após atualização de kernel/firmware.

Conclusão

O patch da Huawei pode simplificar a vida de quem gerencia servidores ARM64, mas não é uma bala de prata. 

O boost por padrão aumenta o potencial de desempenho e também o risco térmico. A decisão ideal passa por medição, documentação e ajuste fino.