O kernel Linux está prestes a ganhar um turbo em um lugar que quase ninguém vê — mas todo mundo sente: o alocador de memória SLUB. A novidade se chama percpu sheaves e, em termos simples, resolve um velho gargalo de performance em máquinas com muitos núcleos. Pense assim: em vez de vários CPUs brigarem por objetos em uma mesma “gaveta” compartilhada, cada núcleo passa a ter um feixe (“sheaf”) próprio de objetos prontos para uso. Menos disputa, mais velocidade. Essa proposta foi enviada por Vlastimil Babka (SUSE) em uma série de patches que já está na versão v7 e pode estrear no ciclo do Linux 6.18 — se nada atrapalhar no caminho.
O problema: a disputa por memória no SLUB
Se você já tentou pegar talheres numa gaveta durante um almoço de família, sabe: quando muita gente acessa o mesmo recurso ao mesmo tempo, rola fila. O SLUB é rápido, mas em cargas de trabalho intensas — especialmente em servidores e estações com dezenas de núcleos — aparece contenção de locks ao gerenciar os “parciais” por CPU e listas compartilhadas. Resultado? Alocações que deveriam ser instantâneas passam a esperar por um cadeado. Percpu sheaves ataca justamente esse ponto: diminuir a frequência com que os núcleos precisam sincronizar entre si para conseguir objetos.
A solução: “sheaves” por CPU
A ideia central é criar uma camada de cache por CPU e baseada em arranjos para o Linux SLUB allocator, de modo opt-in (ativada por cache, conforme o caso). Isso dá a cada núcleo um “feixe” de objetos, pronto para alocar/devolver sem bater em estruturas compartilhadas. O desenho preserva compatibilidade com recursos importantes (como slub_debug e ambientes NUMA) e, com o amadurecimento da série, passou a cobrir casos de uso do dia a dia do kernel. O nome “sheaf” — “feixe” — foi sugerido por Matthew Wilcox, numa referência às antigas “magazines” do SLAB sem trazer a bagagem do termo clássico; o trabalho é liderado por Babka, com colaboração de nomes como Liam R. Howlett (Oracle), entre outros.
Resultados promissores nos benchmarks
“Bonito no quadro” não basta — e aqui há números. Em microbenchmarks in-kernel comparando alocações e liberações com e sem percpu sheaves, os ganhos variam de 11% até 31%, dependendo do tamanho dos lotes e se há controle de memória por cgroups (memcg). Em cenários com lotes de 100 itens, por exemplo, a melhora chega a 31% sem memcg e ~25% com memcg; em lotes pequenos (1 a 10), há acelerações consistentes na casa de 11–17%. Em troca, o overhead quando as sheaves estão presentes mas desativadas ficou por volta de ~2,4% em um caso — aceitável, sobretudo se a estratégia for generalizar o uso no futuro.
Por que isso importa agora: maple tree e VMAs mais ágeis
A mudança não é “otimização por esporte”. O kernel vem modernizando a forma de gerenciar as Virtual Memory Areas (VMAs) com a maple tree — uma B-tree voltada a faixas não sobrepostas, hoje peça-chave do gerenciamento do espaço de endereços de cada processo. Operações de escrita/alteração na árvore (split/merge de nós, criações e remoções de VMAs) frequentemente passam por alocações pequenas e intensivas. Baratear essas alocações — isto é, torná-las mais baratas e rápidas — dá fôlego direto ao subsistema de memória e reduz contenção em máquinas grandes. A própria série v7 já traz patches que convertem os caches de vm_area_struct e de nós da maple tree para usar percpu sheaves.
O estado da proposta e o que esperar
Estamos na v7 de uma série de patches abrangente que refatora o coração do SLUB e adiciona a camada de percpu sheaves como opção por cache. O pacote inclui testes, conversões seletivas (maple tree e VMAs) e uma longa trilha de revisões, o que indica maturidade — além de ter atraído revisões de desenvolvedores de memória e MM. A imprensa especializada já aponta que a janela do Linux 6.18 é uma meta plausível para entrada, embora a palavra final sempre fique com os mantenedores após a revisão final.
O impacto para quem usa linux no dia a dia
Vai dar para “sentir” isso fora do laboratório? Em workloads de servidor, bancos de dados, hypervisors, navegadores e qualquer coisa que estresse o subsistema de memória com muitas operações pequenas, a resposta tende a ser sim — especialmente em máquinas com 16, 32, 64 (ou mais) núcleos, onde qualquer contenção se multiplica. Como a maple tree é fundamental para organizar as VMAs de todo processo, acelerar essas operações tem efeito cascata: menos espera em locks, menores latências e melhor performance global do sistema. Para o usuário final, isso significa um kernel Linux mais responsivo sob pressão; para quem empacota distros e administra infra, significa mais previsibilidade e escalabilidade.
