A comunidade do kernel está abrindo caminho para um upgrade importante no subsistema de alocação de memória: as SLUB percpu sheaves. A proposta, liderada por Vlastimil Babka (SUSE), adiciona ao SLUB uma camada de cache por-CPU baseada em arranjos — batizada de sheaves (feixes) e organizada por NUMA em barns (celeiros). A ideia é simples e poderosa: baratear os caminhos rápidos de alocação/liberação reduzindo atomics e contenções, enquanto cria ganchos eficientes para kfree_rcu() e uma API de pré-alocação destinada a trechos críticos. Os primeiros candidatos a se beneficiar são as estruturas de VMA e os nós da maple tree.
Como funciona e por que importa
Em vez de depender dos partial slabs por CPU, as sheaves mantêm arranjos locais por CPU e um barn compartilhado por nó NUMA. Isso evita arrays “alien”/“shared” do SLAB, reduz travamentos em filas compartilhadas e honra restrições de NUMA (quando há exigência de alocação local, as sheaves são ignoradas). Um patch complementar também faz a liberação de objetos remotos pular as sheaves, para manter localidade. Resultado: menos bloqueios, menos atomics e mais previsibilidade nos caminhos rápidos de alocação.
Outro ganho prático está no tratamento de kfree_rcu(): objetos liberados podem ir para uma sheaf dedicada por CPU e só são enviados ao RCU quando o feixe enche; depois do grace period, esse feixe pode voltar a servir alocações, reciclando objetos com custo menor do que liberar e realocar individualmente. Há ainda uma API de pré-alocação: você “pega emprestado” um feixe pré-preenchido para operações que não podem bloquear e têm um teto de alocações — perfeito para escritas na maple tree..
Compatibilidade não foi esquecida: sheaves são opt-in por kmem_cache e, quando slub_debug está ativo (ou em SLUB_TINY), a camada simplesmente não é criada para aquele cache, preservando os ganchos de depuração nos caminhos lentos. Assim dá para medir, comparar e evoluir sem quebrar o que já existe.
Números que chamam atenção
No microbenchmark de referência (Ryzen 7 5700), apenas carregar o código de sheaves sem usar (batch=10) introduziu ~2,4% de sobrecarga — um custo considerado aceitável, dado o plano de migrar amplamente para sheaves no futuro. Habilitando sheaves (capacidade 32), surgem ganhos consistentes, por exemplo: +17,2% (batch=1, sem memcg), +15,3% (batch=10), +31,0% (batch=100) e +30,2% (batch=1000); com embaralhamento (shuffle), aparecem cenários como +12,6% (batch=10) e +28,6% (batch=100). São números de microbench, mas ajudam a explicar o entusiasmo do time. (lkml.org)
Há também indícios positivos fora do laboratório: testes independentes reportaram melhoras significativas (>10%) em will-it-scale em plataformas AMD de muitos núcleos, com impactos neutros na maioria dos demais benchmarks — um bom sinal para cargas reais em servidores grandes.
Foco imediato: VMA e maple tree
O impulso inicial vem do esforço para escalar o locking de VMA e as operações da maple tree (estrutura central para gerenciar intervalos de memória no kernel). Por isso, os caches dessas estruturas já aparecem como usuários iniciais das sheaves. Parte das conversões de maple tree foi até separada em uma série própria, facilitando a revisão e evitando conflitos no fluxo principal.
Quando chega ao kernel?
O status mais recente (10 de setembro de 2025) é a versão v8 da série, baseada em Linux 6.17-rc3, com nota explícita de que o v8 “substitui/estende o v7 em slab/for-next” — ou seja, está na fila para a próxima janela de merge. A expectativa do ecossistema é que as sheaves estreem no Linux 6.18, salvo tropeços de última hora.
Leitura técnica essencial
- [PATCH v8 00/23] SLUB percpu sheaves — descrição, motivação, compatibilidade (slub_debug/SLUB_TINY), microbenchmarks e status (for-next). (lkml.org)
- Maple tree & sheaves (série separada) — conversões e testes relacionados. (lkml.org)
- Patches auxiliares (ex.: pular liberação remota) — detalhes de localidade e NUMA. (lkml.org)
Em resumo: sheaves é um passo cirúrgico (e reversível) para destravar desempenho no SLUB onde mais dói hoje — VMA e maple tree — com um desenho que respeita depuração, NUMA e casos críticos. Se tudo correr bem, veremos essa peça chegar ao Linux 6.18 e, a partir daí, ganhar tração em mais caches do kernel.
