Uma mudança arquitetônica no kernel Linux para a plataforma ARM64 está prestes a trazer um ganho de performance e eficiência. Uma nova série de patches propõe mover o buffer usado para salvar o estado de ponto flutuante e SIMD (FPSIMD) do modo kernel diretamente para a stack, em vez de alocá-lo permanentemente para cada processo no sistema. E por que isso importa? Porque aquele “cantinho” reservado em cada task_struct — mesmo quando não é usado — pesa na memória e, no agregado, freia a agilidade do sistema.
O problema da “mochila pesada” em cada processo
Imagine que cada processo do sistema carregasse uma mochila de 528 bytes o tempo todo — era isso o que acontecia com o buffer de FPSIMD no thread_struct (parte do task_struct). Na maioria das vezes, esses dados só são necessários em trechos de kernel que utilizam NEON/FPSIMD (criptografia acelerada, por exemplo) e que podem ser preemptados. Ainda assim, a mochila estava sempre lá, ocupando memória de todos os processos, do servidor de banco ao daemon mais simples. Em máquinas com muitos processos, esse “inchaço” (bloat) fica caro: mais memória consumida, mais pressão de cache, mais bytes viajando nos caminhos críticos de agendamento. No fim, tudo isso se traduz em latência extra — aquela sensação de que interrupções e syscalls respondem “um tico” mais devagar do que poderiam.
A solução: usando a stack para mais agilidade
A proposta de Ard Biesheuvel é elegante: em vez de impor um buffer fixo por processo, o kernel passa a fornecer esse espaço na stack apenas quando um trecho de código entra numa seção NEON (via kernel_neon_begin()), liberando-o ao sair (kernel_neon_end()). Em outras palavras: deixamos a mochila no armário e pegamos só o que precisamos, na hora — é como colocar os itens temporariamente no bolso (a stack), usar, e guardar de volta quando terminar. O ganho prático? Menos memória por processo, menos bloat de task_struct, menor competição por cache e menos indireções. O acesso à stack costuma ser mais direto que a leitura via ponteiros persistentes espalhados por estruturas de tarefa ou variáveis per-cpu, o que reduz latência em caminhos críticos (interrupções e syscalls tipicamente se beneficiam). Resultado: Linux ARM64 performance melhor naquilo que mais sentimos no dia a dia — resposta rápida.
As mudanças táticas que habilitam a otimização
Antes de mover o buffer para a stack, foi preciso preparar o terreno. Um passo importante foi “fechar” o contrato de uso de NEON no kernel: kernel_neon_begin() e kernel_neon_end() agora precisam ser chamados no mesmo escopo. Por quê? Porque assim o kernel pode alocar com segurança o buffer temporário na mesma stack frame que abre a seção NEON, garantindo que esse espaço continue válido até o final do bloco. Além disso, trechos do subsistema de crypto em ARM64 foram ajustados para não “ceder” desnecessariamente a unidade NEON — hoje, seções NEON no kernel são preemptíveis, e aquelas rendições artificiais deixavam desempenho na mesa. Com o contrato de escopo bem definido e os chamadores ajustados, a troca do buffer permanente por um buffer na stack fica transparente e segura.
Impacto prático: menos memória, menos latência, mais throughput
O benefício é duplo. Primeiro, economia de memória sistêmica: 528 bytes a menos por processo deixam de inflar o task_struct. Em servidores com dezenas de milhares de processos, isso não é detalhe — é uma economia que melhora a densidade de workloads e reduz pressão no subsistema de MM. Segundo, redução de latência: a vida das interrupções e das syscalls fica mais fácil quando há menos bloat, menos indireção e quando os dados temporários estão onde deveriam estar — na stack, pertinho do que está sendo executado. Isso pode se refletir em respostas mais rápidas de serviços que fazem uso intensivo de criptografia acelerada por NEON, pipelines de rede e qualquer caminho quente em que o kernel precisa salvar/restaurar estado de FPSIMD ao alternar de contexto.
O que vem agora (e onde isso entra no kernel)
Trata-se de uma série de patches que primeiro prepara o código de crypto para o novo contrato (evitando yields desnecessários e alinhando kernel_neon_begin()/end() ao mesmo escopo) e, por fim, implementa a alocação na stack dentro do código central de FPSIMD do ARM64. A expectativa natural é que essa mudança seja considerada para uma janela de merge futura (provavelmente em torno do Linux 6.18), após revisão e testes — o tipo de evolução que mostra como o kernel Linux segue lapidando detalhes para extrair performance onde importa. Para quem vive de latência baixa e previsível, é uma daquelas otimizações “cirúrgicas” que somam.
Em uma linha: menos mochila, mais bolso — e um Linux ARM64 mais leve, responsivo e eficiente.
