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.
