Uma grande refatoração no subsistema de swap do kernel Linux está em andamento — e os primeiros resultados são empolgantes: ganhos de performance de até 28% em cenários de forte pressão de memória. Liderada por Kairui Song (com base em uma ideia de Chris Li), a proposta introduz uma nova swap table que substitui o antigo swap cache baseado em XArray. Em testes variados (de vm-scalability a build do kernel e Redis/Valkey), o throughput e a responsividade melhoram de forma consistente. (Patchew)
contexto de upstream — mm-unstable
Andrew Morton já atualizou o branch mm-unstable para a série v3, o que indica que essa reformulação deve seguir para a próxima janela de merge (Linux 6.18), após a estabilização no ciclo de testes.
Adeus ao XArray, olá à “swap table”
Pense no XArray como um grande catálogo de biblioteca com um sistema de indexação hierárquico: para achar “um livro” (uma página anônima trocada para o swap), você percorre vários níveis da árvore. Funciona — mas debaixo de pressão, esse caminho longo vira gargalo. A nova swap table muda o jogo: cada “estante” (um cluster de swap) ganha um índice direto local — um array atômico por cluster — que permite localizar rapidamente o que você precisa. Resultado? Menos saltos, menos contenção de lock, muito mais fluidez quando vários processos disputam memória ao mesmo tempo.
Tecnicamente, a fase I introduz a infraestrutura da swap table e a usa como backend do swap cache. Cada cluster aloca dinamicamente um array atômico que cobre todos os slots daquele cluster, substituindo o mapeamento via XArray por lookups diretos e locais. Por enquanto, o antigo swap_map continua existindo (coexistência temporária), mas a ideia é fundi-lo à swap table nas próximas fases — o que deve reduzir o uso de memória em relação ao desenho anterior. Além do ganho de performance, a base de código do swap fica mais limpa e coesa.
Ganhos de performance no mundo real
Os números falam por si. Nos testes publicados junto à série de patches, a Linux swap performance evoluiu de forma clara em máquinas que vão de um ARM de 8 cores/1 GB até servidores x86_64 com 48c/96t e 128 GB:
- vm-scalability (PMEM como swap):
+28,55% de throughput agregado; -27,82% no system time; free latency -24,92%. - Build do kernel (tmpfs com ZRAM/ZSWAP):
melhorias de system time de até -6,11% sob alta pressão de memória, com reduções proporcionais no real time. - Redis/Valkey (BGSAVE ativado):
+7,19% e +6,12% de RPS em dois cenários distintos; sem BGSAVE, as variações ficaram próximas de zero (ligeiramente negativas em <0,1%), atribuídas ao estado transitório em que swap_map e swap table ainda coexistem (algo que deve desaparecer nas próximas fases).
Esse salto vem, principalmente, de um caminho de lookup mais raso e de menor contenção de lock no acesso ao swap cache — especialmente benéfico em cargas com muitos faults/trocas simultâneas (containers sob pressão, bancos em persistência background, builds paralelos, etc.). Em alguns cenários extremos, a remoção de workarounds antigos também destravou ganhos adicionais (ex.: HDD swap significativamente mais rápido com usemem).
Por que isso importa para você?
Se você administra servidores com ZRAM ou ZSWAP, orquestra pods que estouram limites de memória, ou compila projetos pesados em máquinas com RAM apertada, qualquer redução na sobrecarga do swap vira responsividade percebida: menos stalls no GC, p99 mais baixo em picos de alocação, builds que “respiram” melhor sob throttling. A nova swap table não é um “tuning” pontual: é uma troca de arquitetura — como sair de um mapa rodoviário cheio de rotatórias para vias expressas por bairro. O destino é o mesmo; o caminho, não.
E há um aspecto de manutenção que costuma passar batido: ao unificar e simplificar o código do subsistema, o kernel abre espaço para otimizações futuras (e até para reduzir o consumo de memória do próprio metadata de swap quando o swap_map for incorporado de vez). No dia a dia, isso significa menos tempo perdido “lutando” com detalhes de implementação e mais espaço para melhorar o que realmente importa: latência e throughput sob pressão.
O que vem a seguir
Estamos na fase I: a swap table já atua como o novo backend do swap cache e entrega ganhos imediatos. As próximas fases devem absorver o swap_map para dentro dessa tabela, consolidando metadata e, potencialmente, reduzindo o uso de memória — além de abrir caminho para novas melhorias (por exemplo, estratégias de readahead e contabilidade mais eficientes em cenários com folios grandes). Com o código já aceito no mm-unstable, a expectativa é vê-lo amadurecer rumo ao Linux 6.18.
