- O patch propõe o fim da escolha obrigatória entre kernels de 4K ou 64K, permitindo tamanhos de página híbridos no sistema.
- Processos de alto desempenho, como bancos de dados, podem usar páginas de 64K enquanto o restante do sistema economiza RAM em 4K.
- A solução utiliza a separação nativa do hardware Arm entre tabelas de páginas do usuário e do kernel para emular a nova ABI.
- Desenvolvedores sêniores da LKML discutem os riscos de sincronia e a complexidade de gerenciar o Page Cache em tamanhos variados.
- A novidade está em fase de debate para o ciclo do Kernel Linux 7.0, visando uma imagem de sistema universal para dispositivos Arm.
O desenvolvedor Dev Jain, em colaboração com Ryan Roberts, propôs uma mudança estrutural significativa para a arquitetura arm64 que pode encerrar o dilema entre performance e consumo de memória. O patch introduz o conceito de “tamanho de página por processo”, permitindo que o Kernel Linux 7.0 ofereça a eficiência de páginas de 4K para o sistema em geral, enquanto permite que aplicações específicas operem com páginas de 64K para ganho de desempenho.
A proposta foca em resolver o gargalo de performance em processadores Arm de alto desempenho. Atualmente, administradores precisam escolher entre um kernel de 4K (econômico em RAM, mas mais lento em processamento pesado) ou 64K (rápido, mas com alto desperdício de memória em arquivos pequenos). Com esta implementação, o sistema ganha a flexibilidade de rodar uma ABI (Interface Binária de Aplicação) híbrida, otimizando cargas de trabalho específicas sem penalizar o restante do hardware.
O que isso significa na prática
Para o usuário comum ou o administrador de sistemas, essa mudança representa o melhor de dois mundos. Imagine um servidor de banco de dados ou uma aplicação de inteligência artificial que performa drasticamente melhor com páginas de 64K devido à redução de latência no acesso à memória. Atualmente, para obter esse ganho, todo o sistema operacional precisaria rodar em 64K, o que faria com que cada pequeno arquivo de configuração de poucos bytes ocupasse, no mínimo, 64K de RAM.
Com o novo patch, o Kernel Linux continua operando em 4K, mas “engana” a aplicação específica, entregando a ela blocos de 64K. Isso reduz o ruído de processamento e melhora o cache, mantendo o consumo de memória sob controle para o restante dos serviços do sistema.
Detalhes da implementação
A implementação técnica baseia-se em uma característica arquitetural do Arm: a separação das tabelas de páginas do usuário e do kernel. O design é dividido em três camadas principais que permitem essa emulação sem quebrar a compatibilidade do sistema.
Primeiro, foi adicionado um “adaptador de ABI” na fronteira das chamadas de sistema (syscalls). Ele converte os endereços e alinhamentos solicitados pelo processo para o formato que o kernel entende. Segundo, o subsistema de gerenciamento de memória (MM) foi ajustado para entregar memória sempre na granularidade exigida pelo processo, utilizando caminhos já existentes de mTHP (multi-size Transparent Huge Pages) e grandes folios.
Por fim, há uma tradução entre a “tabela de páginas Linux” (software) e a “tabela de páginas nativa” (hardware). No caso de um kernel 4K atendendo um app 64K, o código do arm64 mantém uma tabela nativa por processo. Cada operação na tabela de páginas do Linux é traduzida para a geometria nativa de 64K, garantindo que o hardware aproveite os benefícios de ter menos níveis de profundidade na busca de endereços.
Vale lembrar que essa evolução é um desdobramento de esforços contínuos de modernização do subsistema de memória. Como acompanhamos anteriormente no SempreUpdate, a implementação de Large Folios no sistema de arquivos EXT4 já demonstrava ganhos de performance de até 37%, pavimentando o caminho para que o kernel agora consiga gerenciar tamanhos de página de forma ainda mais flexível por processo.
Curiosidades e bastidores da discussão
A recepção na LKML foi marcada por cautela técnica, especialmente vinda de nomes como Matthew Wilcox e David Hildenbrand. O ponto de maior atrito na discussão envolve o “Page Cache”. Como o sistema deve reagir quando um processo de 64K tenta acessar um arquivo que já está em cache em blocos de 4K?
Dev Jain sugeriu descartar o cache existente e reler o arquivo no tamanho maior, mas Wilcox alertou que essa abordagem pode ser “confusa” e difícil de sincronizar em sistemas com uso intenso de arquivos. Outra discussão relevante levantada por Arnd Bergmann é se essa complexidade compensa em comparação ao uso de um kernel fixo de 16K, que seria um meio-termo mais simples. Os proponentes do patch defendem que a flexibilidade total é o único caminho para permitir uma imagem de kernel única para todos os dispositivos arm64 no futuro.
Quando isso chega no meu PC?
Por se tratar de uma mudança profunda no subsistema de memória e na arquitetura arm64, o patch ainda passará por várias rodadas de revisão antes de ser aceito na árvore principal. Dado que o ciclo do Kernel Linux 7.0 acaba de começar com o primeiro Release Candidate (RC1), é possível que a funcionalidade seja consolidada apenas em versões futuras (como o 7.1 ou 7.2) caso os problemas de Page Cache não sejam resolvidos rapidamente. Distribuições voltadas para servidores e computação de alto desempenho (HPC) devem ser as primeiras a adotar a tecnologia.
