Quando o suporte ACPI foi adicionado ao kernel Linux em 2002 — escrito por Andy Grover, commitado por Linus Torvalds — ele incluía uma 'dummy wait op': o sistema lia dados sem propósito algum além de atrasar a próxima instrução até que a CPU pudesse parar completamente com o comando STPCLK#. Isso proporcionava economia de energia e compatibilidade nos primeiros dias, quando alguns chipsets se recusavam a entrar em estados ociosos como esperado.
Vinte anos depois, o engenheiro da AMD Prateek Nayak submeteu um patch do kernel para 'pular a espera dummy para processadores baseados na microarquitetura Zen'. Chips Zen modernos não precisam de tal empurrãozinho, e testes com amostragem baseada em instruções mostraram que a operação dummy ainda consumia tempo significativo que o kernel contabilizava incorretamente como residência em C-state. Vendo todo aquele trabalho de baixo esforço, a CPU se empurrava para C-states mais profundos e lentos, e então levava mais tempo para acordar — prejudicando tarefas que alternam constantemente entre ocupado e ocioso.
As medições foram dramáticas: em execuções de tbench em um sistema Zen3 de soquete duplo, o kernel com patch entregou um aumento de 1.390% na vazão mínima em MB/s e um aumento de 51% na vazão média em MB/s sobre o kernel de linha de base, chegando perto do resultado de desabilitar completamente o estado de sono C2.
Sistemas Intel haviam escapado da maldição legada por uma década graças a um mecanismo ocioso baseado em MWAIT, e Dave Hansen, da Intel, submeteu um patch urgente limitando a espera dummy a sistemas Intel — onde ela não afetaria máquinas 'remotamente modernas' — além de comentários exortando os leitores a migrar para mecanismos ociosos mais modernos. Submetida a tempo, a correção poderia entrar no kernel Linux 6.0 que seria lançado na semana seguinte.
Uma leitura no-op de 2002 era interpretada erroneamente pelo gerenciamento de energia como prova de carga leve, empurrando núcleos Zen para sono profundo — removê-la elevou a vazão mínima em 1.390%.
O diagnóstico é a genialidade: a amostragem baseada em instruções revelou que o tempo desperdiçado estava sendo rotulado erroneamente como sono saudável, transformando um bug de contabilização do gerenciamento de energia em um penhasco de desempenho visível.
A correção custa um branch — pular a espera dummy no Zen — mas recupera catorze vezes a vazão mínima, uma proporção raramente alcançável por qualquer otimização de trabalho real.
É um espécime vivo de dívida técnica: código adicionado para chipsets de 2002 sobreviveu duas décadas e múltiplas gerações de CPU porque nada nunca falhou, apenas ficou mais lento.
Camadas de compatibilidade sobrevivem ao hardware que servem: a menos que alguém as reaudite contra silício novo, um no-op de 20 anos pode se tornar um imposto invisível que parece um problema do chip.
O patch Zen de Nayak e o acompanhamento urgente de Hansen limitando a espera dummy a sistemas Intel foram submetidos no final de setembro de 2022, a tempo de serem considerados no kernel Linux 6.0 que Torvalds esperava lançar na semana seguinte. O patch da Intel também adicionou comentários incentivando a migração para mecanismos ociosos modernos. O Ars Technica relatou não haver problemas residuais para sistemas AMD depois que o patch foi aplicado.
CONFIRA AS EVIDÊNCIAS
As fontes
- 20-year-old Linux workaround is still slowing down AMD systems Ars Technica · arstechnica.com ·