Ganhos de performance de dois dígitos em uma área crítica do kernel não aparecem todo dia. Uma nova proposta para o gerenciamento de swap no Linux — a “swap table” — promete reduzir a contenção em máquinas com muitos núcleos e destravar melhorias palpáveis de Linux swap performance sob pressão de memória. Em testes práticos, há leituras com salto de +33% em throughput e ganhos consistentes em compilação de kernel e bancos de dados in-memory sob carga.
O gargalo do swap cache atual
Pense numa única porta giratória por onde todo mundo precisa passar quando a RAM acaba e o sistema recorre ao swap. Hoje, em cenários com múltiplos núcleos trabalhando pesado, vários threads tentam acessar a mesma “fila” (a estrutura do swap cache), gerando briga por travas e tempo de CPU desperdiçado. Resultado? Mesmo com storage rápido (ZRAM, PMEM, NVMe), o caminho de software vira o gargalo — exatamente quando você mais precisa de fluidez.
A nova solução: “swap table”
A ideia da “swap table” é trocar a fila única por várias portinholas: estruturas menores, mais locais, que reduzem a chance de dois núcleos trombarem na mesma entrada de dados. Na prática, o kernel passa a distribuir melhor o acesso, diminuindo a contenção e deixando o hardware trabalhar. Não é uma mudança cosmética: é a fase I de uma refatoração maior no subsistema, que começa usando a swap table como backend do cache de swap e prepara o terreno para simplificações futuras e até redução de uso de memória do próprio kernel. E tem pedigree: a discussão evoluiu no fórum de alto nível LSF/MM/BPF, e a série foi enviada por Kairui Song (Tencent) à lista de memória do kernel.
Resultados de performance na prática
Os números falam por si — todos os casos testados ficaram iguais ou mais rápidos, com destaque sob pressão pesada de memória:
- vm-scalability / usemem (PMEM como swap): throughput subiu de 4775,18 MB/s para 6381,43 MB/s (+33,63%) e o tempo de CPU de sistema caiu -27,36% em um dos cenários; outro teste mostrou +23,73% de throughput e -16,87% no tempo de sistema.
- Compilação do kernel (tmpfs com ZRAM/ZSWAP, diferentes limites de memória): reduções de ~5–10% no tempo de sistema em diversas matrizes de -j e memória — e quedas adicionais no tempo “real” (parece pouco, mas em builds longos, acumula).
- Redis/Valkey (ARM64 VM, 1,5 GB RAM; dataset 2,5 GB): com BGSAVE (estressa o cache de swap), o throughput subiu ~6–7%; sem BGSAVE, ficou essencialmente estável (ligeira queda <1% atribuída ao estado de transição desta primeira fase).
Em português claro: quando a memória aperta, o kernel briga menos consigo mesmo e entrega mais trabalho útil por segundo. Para quem compila, roda serviços em contêineres com limites agressivos de memória, usa ZRAM/ZSWAP em laptops ou espreme VMs em hosts densos, é a diferença entre “engasgar” e “seguir respirando”.
Por que isso importa para você?
Porque Linux swap performance não é um detalhe acadêmico: ela determina a dignidade do sistema sob estresse. A “swap table” ataca a raiz do problema (contenção) sem exigir truques do usuário ou knobs obscuros. E, como é só a primeira fase de uma reforma maior, a tendência é melhorar mais: além de manter (ou reduzir) a pegada de memória do próprio kernel, essa base unificada abre caminho para otimizações adicionais em swap-in, folios maiores, e interações mais limpas com ZSWAP/ZRAM e cgroups. Em suma, menos complexidade histórica, mais espaço para evoluir.
Quem está por trás e em que estágio está
A série foi apresentada por Kairui Song e deriva de debates técnicos no LSF/MM/BPF, um encontro onde mantenedores do kernel alinhavam mudanças estruturais. Esta fase I foca em trocar o backend do swap cache, já mostrando ganhos de dois dígitos sem regressões sob pressão global — exatamente o tipo de resultado que costuma ganhar tração no processo de revisão.
