Não começaram nada bem os trabalhos em torno do novo kernel Linux 6.8, o primeiro a ser totalmente feito neste ano. Assim. que começou a mexer nele, Linus Torvalds anuncia uma regressão de desempenho desagradável com o início do código Linux 6.8. Não é muito comum ouvir o próprio Linus Torvalds fazendo alarmes sobre as regressões de desempenho do kernel Linux, mas isso aconteceu esta noite com a janela de mesclagem do Linux 6.8 em andamento.
O sistema AMD Ryzen Threadripper de Torvalds de repente estava sofrendo com tempos de compilação muito mais longos, pelo menos como resultado do novo código para este kernel. Chamando a atenção esta mensagem de Linus Torvalds sobre uma “regressão de desempenho horrenda” com código programado para Linux 6.8. Ele observou:
“Apenas uma observação de que estou atualmente dividindo nesta fusão para uma regressão de desempenho horrenda.Isso faz com que minha compilação de kernel vazia passe de 22 segundos para 44 segundos, e torna uma compilação de kernel completa enormemente mais lenta também. Eu ainda não terminei a bissetriz, mas agora está dentro apenas essa puxada, então já posso dizer que vou reverter algo aqui, porque isso tem tornado minha janela de mesclagem miserável.Você foi avisado, disse Linus.”
Linus Torvalds anuncia regressão de desempenho desagradável com o início do código Linux 6.8
Isso foi em resposta às mudanças do agendador para o Linux 6.8. Para regredir uma carga de trabalho como as velocidades de compilação de código sendo reduzidas pela metade é bastante surpreendente, pois enquanto o kernel Linux carece de integração contínua (CI) comum e robusta, parece que os desenvolvedores de kernel responsáveis pelas mudanças notariam uma mudança tão dramática… Especialmente se o código passou pelo linux-next e afins.
Há pouco tempo acrescentou:
Eu acho que não deve ser surpresa que o resultado é 9c0b4bb7f6303c9c4e2e34984c46f5a86478f84d é o primeiro compromisso ruim, mas para reverter limpo eu terei que reverter tudo de b3edde44e5d4 (“cpufreq/schedutil: Use uma frequência de referência fixa”) f12560779f9d (“sched/cpufreq: Rework iowait boost”) 9c0b4bb7f630 (“sched/cpufreq: Rework schedutil governor performance estimation”)
Isso está em um AMD Ryzen Threadripper 3970X de 32 núcleos (64 threads), fwiw. Vou manter essa reversão na minha árvore de testes privada por enquanto (para que eu tenha uma máquina funcionando novamente), mas vou movê-la para o meu ramo principal em breve, a menos que alguém tenha uma solução rápida para esse problema.”
A partir dessa mensagem, é interessante ver Linus Torvalds ainda balançando uma estação de trabalho AMD Ryzen Threadripper 3970X. Em 2020, Torvalds mudou para o Threadripper após 15+ anos com sistemas Intel. É um pouco surpreendente que, quase quatro anos depois, ele ainda esteja confiando no cavalo de batalha Threadripper 3970X, considerando o desempenho muito mais rápido agora disponível, especialmente com os sistemas de classe da série Ryzen Threadripper 7000. De qualquer forma, a regressão se deve a uma regressão do governador schedutil da CPUFreq, ao que parece.
O retrabalho de estimativa de desempenho do governador schedutil da CPUFreq foi de autoria de Linaro e teve como objetivo lidar com os limites da uclamp. Mas parece que algo lá dentro está causando problemas. Até o momento, não houve outras respostas ou mensagens de Torvalds sobre o assunto.
Mas pelo menos com isso sendo detectado cedo e pelo próprio Torvalds e ainda faltando mais de uma semana para o Linux 6.8-rc1, espera-se que seja resolvido em breve e bem antes do lançamento estável do Linux 6.8 que será lançado em março.
