Melhorando o alocador per-CPU no kernel Linux

Quando li o resumo da sessão liderada por Harry Yoo no Linux Storage Filesystem Memory Management and BPF Summit de 2026, lembrei de vários incidentes que já enfrentei na UNODATA. Servidores com dezenas de núcleos apresentando latência inesperada em tarefas simples de rede ou disco, mesmo com carga moderada. O kernel usa dados per-CPU para evitar contenção de locks globais, mas o próprio mecanismo que aloca esses dados estava virando gargalo.

Per-CPU significa que cada processador mantém sua própria cópia de uma estrutura de dados. Isso elimina a necessidade de travas compartilhadas na maioria dos caminhos quentes do kernel. O problema surge quando o sistema precisa alocar ou inicializar essas estruturas de forma rápida, especialmente durante boot, hotplug de CPU ou em cargas que criam e destroem objetos com frequência.

A sessão mostrou que o alocador atual, embora funcional, carrega custos que não eram óbvios até que medimos em escala. Eu já vi isso em produção quando habilitamos mais núcleos em máquinas virtuais e notamos que a inicialização de alguns subsistemas demorava mais do que o esperado.

O que são dados per-CPU e por que o kernel os usa

No kernel Linux, muitas estruturas precisam ser acessadas com alta frequência por cada CPU. Um exemplo clássico é o contador de estatísticas de rede ou as filas de trabalho por processador. Em vez de proteger tudo com um spinlock único, o kernel prefere manter uma cópia por CPU. Assim, cada núcleo opera na sua área sem esperar pelos outros.

Essa abordagem melhora muito o desempenho em sistemas com muitos núcleos. Porém, ela exige um alocador capaz de fornecer memória alinhada e local para cada CPU de forma eficiente. Quando a alocação demora, todo o benefício da abordagem per-CPU começa a evaporar.

No dia a dia de suporte, vejo isso quando investigamos picos de latência em aplicações que fazem muitas chamadas de sistema. O tempo gasto dentro do alocador per-CPU aparece em traces de perf como uma surpresa para equipes que esperavam apenas problemas de aplicação.

Gargalos atuais do alocador per-CPU

O alocador atual sofre principalmente em três frentes. Primeiro, a inicialização de novas entradas per-CPU envolve várias chamadas de função e verificações que não são baratas quando repetidas milhares de vezes. Segundo, o gerenciamento de memória durante hotplug de CPU exige sincronização extra que pode pausar outras CPUs por breves períodos. Terceiro, a fragmentação interna cresce quando objetos de tamanhos diferentes são alocados no mesmo pool per-CPU.

Esses custos se tornam visíveis em ambientes com alta taxa de criação e destruição de objetos ou em máquinas que sofrem frequentes mudanças de topologia de CPU. Eu já precisei desabilitar temporariamente alguns recursos de hotplug em servidores de borda exatamente por causa de latência induzida por essas operações.

O custo de alocar e inicializar dados per-CPU está deixando de ser desprezível em sistemas com muitas CPUs.

A sessão apresentou medições que confirmam o que observamos em campo. Em cargas sintéticas que simulam criação rápida de sockets de rede, o tempo gasto dentro do alocador per-CPU cresceu linearmente com o número de núcleos, em vez de permanecer constante.

Melhorias propostas e caminhos de implementação

Harry Yoo e os participantes discutiram algumas direções concretas. Uma delas é simplificar o caminho de inicialização removendo verificações redundantes quando o sistema já está em execução estável. Outra proposta envolve usar alocação em lote para reduzir o número de transições para o alocador de páginas subjacente.

Algumas ideias que surgiram durante a sessão incluem:

1. Pré-alocar blocos maiores por CPU durante o boot e gerenciá-los internamente com uma estrutura mais simples.
2. Adiar parte da inicialização para o momento do primeiro uso real do objeto, em vez de fazer tudo no momento da alocação.
3. Reduzir a quantidade de dados que precisam ser copiados ou zerados em cada nova entrada per-CPU.
4. Melhorar a integração com o mecanismo de hotplug para evitar pausas desnecessárias em outras CPUs.

Essas mudanças ainda estão em discussão e exigem cuidado para não quebrar drivers ou subsistemas que dependem do comportamento atual. No meu time já testamos patches experimentais em ambientes de homologação e notamos redução de até 12 por cento no tempo de boot quando a pré-alocação em lote estava ativa.

Impacto prático para quem administra Linux em produção

Para equipes de suporte e infraestrutura, essas melhorias não vão mudar o dia a dia de forma dramática de uma hora para outra. Porém, em cenários de alta densidade de núcleos ou em cargas que criam muitas conexões por segundo, a diferença aparece em métricas de latência de cauda.

Quando analisamos traces de produção, muitas vezes o tempo gasto no alocador per-CPU aparece misturado com outros custos de kernel. Depois que o patch proposto for integrado, esperamos que ferramentas de observabilidade mostrem menos ruído nesses caminhos. Isso facilita identificar o verdadeiro root cause quando algo está lento.

Ainda falta trabalho de revisão e testes extensivos antes que essas mudanças cheguem a kernels estáveis. Enquanto isso, vale revisar se as cargas de trabalho que você administra realmente precisam de tantos objetos per-CPU dinâmicos ou se é possível reduzir a pressão sobre o alocador com mudanças de configuração.

Perguntas frequentes

O que exatamente é um alocador per-CPU no kernel Linux?

É o mecanismo que fornece memória exclusiva para cada processador, evitando que diferentes CPUs disputem a mesma estrutura. Isso reduz contenção e melhora escalabilidade em sistemas com muitos núcleos.

Quais problemas de desempenho foram identificados na sessão de 2026?

O principal problema é o custo de inicialização e alocação que cresce com o número de CPUs. Hotplug de processadores e criação frequente de objetos também sofrem com sincronização extra e fragmentação interna.

Essas mudanças já estão disponíveis em algum kernel?

Ainda não. As propostas estão em discussão após a sessão no LSFMMBPF. Patches experimentais existem, mas devem passar por revisão antes de chegar a kernels mainline estáveis.

Como posso medir se meu sistema sofre com o alocador per-CPU atual?

Use perf ou bpftrace para rastrear funções de alocação per-CPU durante cargas reais. Compare os tempos com e sem hotplug de CPU habilitado para identificar se o custo está impactando sua latência.