Antes de Linus Torvalds perder sua internet e energia devido a uma tempestade de neve que impactou a janela de integração do Linux 6.8, seu fim de semana já estava em mau estado devido a uma queda de desempenho com o novo código do Linux 6.8 que estava causando a construção de seu kernel Linux. É o dobro do que era com os núcleos anteriores. Um engenheiro AMD Linux conseguiu reproduzir a regressão e, com os principais desenvolvedores, agora existe uma solução confirmada para esse problema no código de agendamento mais recente.
Na discussão da regressão significativa de desempenho relatada por Linus Torvalds que surgiu das mudanças no agendador no Linux 6.8, para split commit, não ficou imediatamente claro para o desenvolvedor envolvido o que causou a regressão. Na discussão que se seguiu, Wise Carney, da AMD, falou mencionado Também pode reproduzir regressão. Em vez de um AMD Ryzen Threadripper topo de linha como o que Torvalds usa, Wyes estava usando um modesto desktop AMD Ryzen 5600G. Uma observação importante que ele mencionou é que isso só será reproduzido se você desabilitar o ACPI CPPC do BIOS e usar o ACPI CPUFreq com o governador Schedutil.
A maioria dos sistemas AMD Zen 2 e posteriores suportam ACPI CPPC, portanto, com núcleos modernos no lado Ryzen, eles normalmente usam o novo driver AMD P-State. Mas para sistemas Zen 2/Zen 3 e anteriores (ou aqueles que desativam o CPPC do BIOS), o driver CPUFreq ainda é usado e o regulador de frequência da CPU padrão geralmente é “Schedutil” para aproveitar as vantagens dos dados de uso do agendador.
Através deste tópico na mailing list, foi sugerida uma correção e discutidas questões específicas desta regressão. Eventualmente, Vincent Guiteau acreditou que tinha uma solução para a regressão e Wise foi capaz de testar o patch com sucesso.
Guittot já foi enviado Programado/Justo: Corrige seleção de frequência para caso instável Como um patch para corrigir essa regressão ruim no novo código do Linux 6.8 ao usar ACPI CPUFreq + Schedutil. Explica com correção:
“Quando a persistência de frequência não está habilitada, get_capacity_ref_freq(policy) retorna a frequência atual e a margem de desempenho aplicada por map_util_perf(), permitindo que o uso exceda a capacidade máxima de computação e selecione uma frequência superior à frequência atual.
A margem de desempenho agora é aplicada no início do pipeline para compensar algumas restrições de uso e não podemos obter uso acima da capacidade máxima de computação.
Devemos usar uma frequência superior à frequência atual para ter a chance de definir um OPP mais alto quando a frequência atual for totalmente utilizada. Aplique a mesma margem e retorne uma frequência 25% maior que a frequência atual para mudar para o próximo OPP antes de usarmos toda a CPU do processador atual.”
Em última análise, foi uma correção de código de uma linha para resolver essa degradação de desempenho que fez com que as compilações vazias do kernel de Linus Torvalds aumentassem de 22 para 44 segundos.
Supondo que tudo continue funcionando bem com o novo patch, a correção deve chegar ao código Git do Linux 6.8 assim que a internet e a eletricidade de Linus Torvalds forem restauradas.