- O patch resolve a ineficiência de gerenciar terabytes de RAM em blocos de apenas 4k no Kernel Linux 7.0.
- Servidores podem recuperar gigabytes de RAM ao reduzir o overhead da struct page de 1,6% para apenas 0,1%.
- A autoria é de Kiryl Shutsemau, da Intel, separando a granularidade virtual da física sem quebrar a ABI de usuário.
- A mudança estrutural impacta o alocador Buddy e o Page Cache, servindo como base para futuras páginas gigantes de 1G.
- A disponibilidade real é esperada para o final de 2026, com foco inicial em datacenters e computação de alto desempenho.
Kiryl Shutsemau, desenvolvedor senior da Intel, submeteu uma proposta de arquitetura para o Kernel Linux 7.0 que visa mudar a definição fundamental de como o sistema operacional gerencia a memória. O patch propõe separar o significado de PAGE_SIZE em dois conceitos distintos: a granularidade do mapeamento virtual (PTE) e o tamanho da alocação física mínima (Buddy). A mudança impacta o Kernel Linux 7.0 ao permitir que o sistema utilize páginas físicas de 16k ou 64k em hardware x86, mantendo a compatibilidade de 4k para o espaço de usuário.
O objetivo central é a escalabilidade em máquinas com múltiplos terabytes de RAM. Atualmente, gerenciar grandes volumes de memória usando blocos de 4k é considerado ineficiente, gerando um overhead massivo em estruturas de dados internas e pressão excessiva em travas globais do sistema.
O que isso significa na prática
Para o administrador de sistemas que opera grandes bancos de dados ou clusters de computação, a mudança reduz drasticamente o “imposto” que o Kernel Linux cobra apenas para existir. Em um servidor com vários terabytes de RAM, cerca de 1,6% de toda a memória é consumida apenas para armazenar a struct page (metadados de cada bloco de 4k). Ao aumentar o tamanho da página física para 64k, esse consumo cai para 0,1%, devolvendo centenas de gigabytes de RAM para as aplicações. O sistema também se torna mais ágil, pois o processador gasta menos tempo traduzindo endereços de memória.
Detalhes da implementação
A mudança introduz os macros PTE_SIZE (para o espaço virtual) e PG_SIZE (para alocação física). O patch corrige a lógica do alocador Buddy e do cache de páginas para operar exclusivamente em unidades de PG_SIZE. Isso exige uma reformulação profunda no tratamento de falhas de página (page faults) e nas Áreas de Memória Virtual (VMAs).
| Recurso | Configuração Atual (4k) | Proposta (64k) | Ganho de Eficiência |
| Overhead de struct page | ~1.6% da RAM | ~0.1% da RAM | 16x menor |
| Tamanho de alocação Order-0 | 4 KB | 64 KB | Redução de fragmentação |
| Pressão no Zone Lock | Alta | Baixa | Menos contenção em máquinas multi-core |
| Suporte a 1G THP | Complexo | Nativo (Order-14) | Caminho simplificado para páginas gigantes |
Um desafio técnico significativo é o tratamento de mapeamentos desalinhados. Se uma aplicação solicitar um mapeamento que não começa em uma fronteira de 64k, o Kernel Linux 7.0 precisará gerenciar o desperdício nas extremidades da VMA ou realizar um empacotamento complexo de tabelas de páginas.
Curiosidades e bastidores da discussão
A discussão na LKML trouxe à tona o fato de que propostas similares foram feitas há quase 20 anos, mas nunca avançaram devido à complexidade. Peter Zijlstra lembrou de esforços de 2007 que tentavam algo parecido. Dave Hansen, arquiteto de memória da Intel, apontou um trade-off crítico: embora economize memória em metadados, a mudança pode causar desperdício no Page Cache se o sistema lidar com muitos arquivos pequenos (menores que 64k), pois cada arquivo ocupará no mínimo um bloco inteiro de memória física.
Kiryl mencionou que sua Prova de Conceito (PoC) já consegue bootar um shell básico, embora ainda apresente instabilidades. O tom da conversa na lista de e-mails indica que, apesar de ser uma mudança invasiva em quase 400 arquivos, há um forte interesse comercial para viabilizar servidores x86 de próxima geração.
Quando isso chega no meu PC?
A proposta está em fase inicial de RFC (Request for Comments) para o ciclo do Kernel Linux 7.0. Dada a natureza sensível da mudança no subsistema de memória, o código passará por meses de auditoria pesada. É improvável que chegue às distribuições domésticas (como Ubuntu ou Fedora) antes do final de 2026. O recurso será inicialmente direcionado a Kernels compilados especificamente para datacenters e ambientes de alto desempenho.
