- Otimização perigosa: por que o kernel linux 6.19 e 7.0 engasgam com tarefas simples de memória
- Otimização x realidade: a tentativa de acelerar servidores com "páginas gigantes" (thp) criou um gargalo de verificação que pune o uso de memória padrão (4kb) em até 250%.
- Quem paga a conta: aplicações que dependem de mudanças rápidas de permissão de memória, como android, navegadores web e ambientes java, são as mais afetadas pela lentidão.
- Quem paga a conta: aplicações que dependem de mudanças rápidas de permissão de memória, como android, navegadores web e ambientes java, são as mais afetadas pela lentidão.
- Sinal de alerta: administradores de sistemas devem ter cautela ao migrar de kernels lts antigos (6.16) para as versões mais recentes até que um patch híbrido seja aplicado.
Uma discussão crítica na lista de desenvolvedores do kernel revelou que uma “melhoria” introduzida na versão 6.17 está causando degradação severa de performance em sistemas atuais. O problema afeta a chamada de sistema mprotect, fundamental para navegadores, execução de Java e inicialização de aplicativos, e permanece não resolvido na versão estável atual (6.19) e no candidato a lançamento do kernel 7.0.
A regressão cria um cenário perigoso para administradores de sistemas: atualizar para as versões mais recentes do kernel (6.19 ou testar o 7.0) pode significar uma queda de desempenho de até 250% em operações de memória padrão, tudo em nome de uma otimização que beneficia apenas cenários específicos de servidores.
O motivo da falha: a otimização que virou gargalo
Para entender a falha, é preciso entender como o Linux gerencia memória. A memória é dividida em páginas. O padrão histórico são páginas pequenas de 4KB. Servidores modernos tentam usar “Transparent Huge Pages” (THP), que são blocos gigantes de memória para aumentar a velocidade.
No kernel 6.17, os desenvolvedores implementaram o “loteamento de PTEs” (batching). A ideia era simples: em vez de mudar a permissão de memória página por página, o kernel agruparia várias páginas e mudaria tudo de uma vez. Para THP (páginas gigantes), isso foi um sucesso absoluto, acelerando o processo em 66%.
O problema: Para fazer esse agrupamento funcionar com segurança, o kernel precisa verificar se cada página é elegível para o lote. Essa verificação (a função vm_normal_folio) adicionou um custo computacional alto. Para páginas pequenas (4KB), o custo de verificar se “pode agrupar” é maior do que simplesmente fazer o trabalho individualmente. O resultado é que o processo ficou muito mais lento para o caso de uso mais comum do mundo real.
Como isso influencia as versões atuais (6.19 e 7.0)
Se você está rodando uma distribuição Linux com o kernel 6.19 (o estável mais recente neste cenário) ou testando o 7.0-rc1, seu sistema está executando este código problemático.
- O impacto no agora: Aplicações que alocam e protegem memória frequentemente (como o processo Zygote do Android, ou compiladores JIT em navegadores e linguagens interpretadas) estão gastando ciclos de CPU desnecessários apenas verificando estruturas de memória.
- A armadilha da atualização: Quem migrou do kernel 6.16 (LTS anterior) para o 6.19 esperando melhorias gerais pode notar engasgos sutis nessas aplicações específicas.
- O dilema do 7.0: Os desenvolvedores estão correndo contra o tempo. Eles não podem simplesmente reverter a mudança, pois isso prejudicaria a performance em arquiteturas ARM64 e servidores Enterprise que dependem das melhorias de THP. O desafio para o lançamento final do 7.0 é criar um código híbrido que seja inteligente o suficiente para usar o método novo em páginas gigantes e o método antigo em páginas pequenas.
Dados técnicos da regressão
Os testes de bissecção (o processo de encontrar o erro) mostraram números alarmantes em regiões de memória acima de 400 KiB:
- Kernel 6.16 (Antes): Tempo de execução de ~3.453 nanosegundos.
- Kernel 6.17 até 7.0-rc1 (Atual): Tempo de execução de ~5.993 nanosegundos.
Isso confirma que, para cargas de trabalho que não foram ajustadas para usar massivamente Huge Pages, o kernel atual é objetivamente pior que seu antecessor.
