Acaba de ser corrigida a grave regressão de desempenho do Linux detectada por Torvalds. Mesmo com vários problemas causados por uma tempestade de neve que prejudicou o acesso à eletricidade e à internet, Linus Torvalds apontou essa grave regressão. No entanto, como destacamos, essa tempestade deve impactar ainda mais a janela de mesclagem do Linux 6.8. Isso sem contar que o trabalho do final de semana já estava em uma situação difícil devido a uma regressão de desempenho com o novo código do Linux 6.8 que estava fazendo com que suas compilações do kernel Linux parassem. ser duas vezes mais longo que os kernels anteriores.
Um engenheiro AMD Linux conseguiu reproduzir a regressão e, com os desenvolvedores upstream, agora existe uma possível correção para esse problema no código do agendador mais recente.Na discussão sobre a grande regressão de desempenho relatada por Linus Torvalds que resultou das mudanças no agendador no Linux 6.8, para o commit dividido pela metade não ficou imediatamente claro para o desenvolvedor envolvido o que estava causando a regressão. Na discussão que se seguiu, Wyes Karny, da AMD,
relatou que ele também poderia reproduzir a regressão. Em vez de um AMD Ryzen Threadripper topo de linha como o usado por Torvalds, Wyes estava usando um modesto desktop AMD Ryzen 5600G. Uma observação importante que ele mencionou foi que isso só seria reproduzido se você desabilitasse o ACPI CPPC do BIOS e usasse ACPI CPUFreq com o governador Schedutil.A maioria dos sistemas AMD Zen 2 e mais recentes suportam ACPI CPPC e, portanto, com kernels modernos no lado Ryzen normalmente usam o novo driver AMD P-State.
Mas para sistemas Zen 2/Zen 3 selecionados e mais antigos (ou aqueles que desativam o CPPC do BIOS), o driver CPUFreq ainda é usado e normalmente o regulador de frequência da CPU padrão é “Schedutil” para aproveitar os dados de utilização do agendador.
Corrigida a grave regressão de desempenho do Linux detectada por Torvalds
A partir desse tópico da lista de discussão, um patch foi proposto e as questões específicas em torno desta regressão foram discutidas. No final, Vincent Guittot acredita que tem uma solução para a regressão e Wyes conseguiu testar o patch com sucesso.
Guittot agora enviou sched/fair: Corrigir seleção de frequência para caso não invariável como o patch para corrigir essa regressão desagradável no novo código Linux 6.8 ao usar ACPI CPUFreq + Schedutil. Ele explica com o patch:
Notícias Relacionadas
Linux 6.12
Como compilar e instalar o Linux Kernel 6.12: Tutorial completo e detalhado
Compilar e instalar o Linux Kernel manualmente é uma habilidade valiosa para usuários avançados e entusiastas de tecnologia. Essa prática permite personalizar o kernel para suas necessidades específicas, otimizar o desempenho do sistema e adicionar suporte a hardwares mais recentes antes que eles sejam incluídos nas distribuições padrão. Neste tutorial, você aprenderá a baixar, compilar […]
Linux kernel
Linux 6.13: avanços no gerenciamento de energia com AMD e Intel
O Linux 6.13 marca um novo capítulo no gerenciamento de energia para hardware moderno. Com mudanças significativas para sistemas AMD e Intel, as atualizações incluem desde ajustes no driver AMD P-State até novos valores de EPP para processadores Intel Xeon Granite Rapids. O objetivo dessas modificações é maximizar desempenho e eficiência energética. Lembre-se que o […]
Quando a invariâ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 a utilização ultrapasse a capacidade máxima de computação e selecione uma frequência mais alta que a atual.
A margem de desempenho agora é aplicado no início do caminho para levar em conta algumas limitações de utilização e não podemos obter uma utilização superior à capacidade máxima de computação.
Devemos usar uma frequência acima da frequência atual para ter a chance de selecionar um OPP mais alto quando o atual um se torna totalmente utilizado. Aplique a mesma margem e retorne uma frequência 25% maior que a atual para mudar para o próximo OPP antes de usarmos totalmente a CPU no atual.
No final, foi uma correção de código de uma linha para resolver essa regressão de desempenho que fez com que as compilações vazias do kernel de Linus Torvalds passassem de 22 para 44 segundos.
Supondo que tudo continue testando bem com o novo patch, a correção deve estar chegando ao código Git do Linux 6.8 assim que a Internet e a eletricidade de Linus Torvalds forem restauradas.
