- Resolve o alto consumo e gargalo de gerenciamento de metadados em servidores com múltiplos terabytes de RAM.
- Reduz drasticamente o uso de processamento para gerenciar memória no hardware x86, acelerando bancos de dados pesados.
- A reestruturação massiva de arquitetura foi proposta pelo desenvolvedor Kirill A. Shutemov na LKML.
- Separa a constante PAGE_SIZE em PTE_SIZE e PG_SIZE, permitindo blocos base de 64k com mapeamento virtual contínuo de 4k.
- O patch inicial de testes estruturais, com mais de 3 mil linhas alteradas, está em avaliação no ciclo do Kernel Linux 7.0-rc1.
O desenvolvedor Kirill A. Shutemov enviou uma proposta audaciosa para o Kernel Linux 7.0-rc1 que promete transformar a forma como o sistema gerencia a memória em servidores de altíssimo desempenho. O patch propõe separar o tradicional PAGE_SIZE em dois conceitos distintos, permitindo que o sistema aloque memória em blocos nativos de 64k ou 16k na arquitetura x86, enquanto mantém o mapeamento virtual inalterado em 4k para as aplicações. A mudança impacta diretamente a escalabilidade de máquinas com múltiplos terabytes de RAM.
O que isso significa na prática
Para o usuário ou sysadmin, a gestão de memória atual divide a RAM do computador em pequenos blocos de 4 kilobytes. Em servidores gigantes, com mais de 2 terabytes de memória, controlar milhões desses pequenos blocos exige muito processamento e consome uma fatia considerável da própria RAM apenas com metadados (os registros de organização).
Com a nova arquitetura proposta, o sistema passa a alocar a memória na base em blocos maiores, como 64 kilobytes de uma só vez. Isso reduz severamente o trabalho de contabilidade do sistema operacional, libera processamento e torna a busca por informações na memória mais rápida. O ganho imediato beneficia bancos de dados enormes e cargas de trabalho de alta performance, sem quebrar a compatibilidade com programas convencionais que ainda esperam blocos de 4k.
Detalhes da implementação
Sob o capô do subsistema de gerenciamento de memória (core-MM), o patch promove uma mudança estrutural massiva alterando centenas de arquivos: a macro constante PAGE_SIZE é dividida em PTE_SIZE (que define a granularidade do espaço de endereço virtual) e PG_SIZE (que define o tamanho da alocação base no buddy allocator). Os PFNs (Page Frame Numbers) passam a operar em unidades de PTE_SIZE, enquanto o buddy allocator e o page cache operam em unidades de PG_SIZE.
Essa separação exige uma reformulação profunda no tratamento de page faults e estruturas VMA (Virtual Memory Areas). Um ponteiro struct page e a proteção pgprot_t não são mais suficientes para criar uma entrada PTE, sendo necessário saber o deslocamento exato dentro da página maior.
Abaixo, o impacto arquitetural projetado ao utilizar páginas base de 64k:
| Métrica de gerenciamento | Antes (4k base) | Depois (64k base) |
| Overhead do struct page na RAM | ~1.6% da memória | ~0.1% da memória |
| Alocação de ordem 5 (buddy allocator) | 128 KB | 2 MB |
| Viabilidade de THP de 1G direto no allocator | Inviável | Possível (ordem 14) |
Vale lembrar que o subsistema de memória vem recebendo atenção especial contínua, como acompanhamos recentemente aqui no SempreUpdate durante a conversão das antigas VMA flags para estruturas de Bitmap, o que preparou o terreno no kernel para futuras inovações complexas na memória virtual como esta.
Curiosidades e bastidores da discussão
A thread na LKML expôs um forte debate técnico sobre os trade-offs da medida. Dave Hansen, veterano do Kernel Linux, apontou que a mudança entrega performance, mas cobra seu preço no consumo de RAM devido ao arredondamento excessivo no page cache. Em testes práticos indexando a árvore de arquivos do kernel, o page cache em 64k consumiu cerca de 5 GB adicionais em comparação com o ambiente de 4k.
Liam R. Howlett e David Hildenbrand trouxeram preocupações sobre a pressão de descarte de memória (reclaim) e como ecossistemas como o Android já usam técnicas de emulação de 16k para manter a fluidez. Shutemov defendeu a arquitetura reforçando que, para servidores massivos, sacrificar uma fração do espaço de armazenamento de página para esmagar o overhead de estruturas e reduzir a disputa por travas (zone locks) é um caminho inevitável e altamente lucrativo para a performance global.
Quando isso chega no meu PC?
Como o patch afeta a matemática mais intrínseca da alocação de memória no x86, este é um trabalho de lapidação de longo prazo. O código atual (que gira em torno de 3 mil linhas modificadas) está passando pelas primeiras avaliações severas durante o ciclo do Kernel Linux 7.0-rc1. Mesmo quando for fundido à linha principal de forma estável, o recurso exigirá ativação por parâmetros de boot ou compilação customizada. O foco inicial será totalmente em sistemas operacionais empresariais para datacenters, demorando vários ciclos de lançamento antes que distribuições desktop de uso geral pensem em adotar configurações híbridas de página.
