- O patch no Kernel Linux 7.0-rc1 elimina a reserva antecipada de tabelas de páginas para Huge Pages Transparentes (THP).
- A mudança impacta positivamente o hardware ao economizar cerca de 200 MB de RAM para cada 100 GB mapeados como páginas gigantes.
- A solução, de autoria de Usama Arif, resolve um problema histórico de desperdício silencioso em servidores de alto desempenho.
- O subsistema de memória agora utiliza alocação "lazy", criando tabelas PTE apenas quando a divisão da página gigante é necessária.
- A otimização está disponível no Kernel Linux 7.0-rc1 e deve ser integrada às distribuições estáveis ao longo de 2026.
Usama Arif enviou uma série de 21 patches para o subsistema de gerenciamento de memória (mm) que altera fundamentalmente como o Kernel Linux 7.0-rc1 lida com as Huge Pages Transparentes (THP). O patch corrige um desperdício histórico de memória ao implementar a alocação tardia (lazy) de tabelas de páginas PTE durante a divisão de entradas de diretório médio de páginas (PMD). A mudança impacta diretamente a eficiência de servidores e sistemas que operam com grandes volumes de memória RAM mapeados como páginas gigantes.
O que isso significa na prática
Atualmente, quando o sistema operacional agrupa pequenos blocos de memória em uma “página gigante” (THP) para melhorar o desempenho, ele reserva preventivamente um pequeno bloco de 4 KB (uma tabela de páginas) para o caso de essa página gigante precisar ser dividida novamente no futuro. O problema é que muitas dessas páginas nunca são divididas, permanecendo intactas até o encerramento do processo.
Em servidores de grande porte, esse comportamento gera um desperdício silencioso: aproximadamente 200 MB de RAM são jogados fora para cada 100 GB de memória mapeada como THP. Com a nova lógica proposta para o Kernel Linux 7.0-rc1, o sistema para de reservar esse espaço antecipadamente e só aloca a tabela de páginas no exato momento em que a divisão for necessária.
Essa mudança é um passo crucial na modernização do subsistema de memória. Como já acompanhamos no SempreUpdate, o ciclo 7.0 do kernel tem focado intensamente em flexibilidade, permitindo que o sistema use páginas maiores onde há ganho de performance, sem abrir mão da economia em blocos de 4K para o restante do hardware.
Detalhes da implementação
A mudança técnica remove a necessidade do mecanismo de pré-depósito (pre-deposit) via pgtable_trans_huge_deposit(). O patch introduz a alocação sob demanda dentro do fluxo de __split_huge_pmd(). Uma mudança estrutural importante foi transformar as funções de divisão, que antes não retornavam valores, em funções que retornam inteiros. Isso permite que o Kernel Linux 7.0-rc1 propague erros de memória (ENOMEM) caso a alocação tardia falhe, garantindo que o sistema não tente acessar ponteiros inválidos.
| Recurso | Comportamento anterior | Nova implementação (Lazy) |
| Alocação de tabela PTE | No momento da criação da THP | No momento da divisão (split) da THP |
| Overhead de memória | 4 KB por THP (fixo) | Zero (em uso comum) |
| Gerenciamento de erro | Operação não podia falhar | Tratamento de erro via retorno de int |
| Impacto em 1 TB de THP | ~40 MB por 100GB (Total ~400MB+) | RAM livre para outras tarefas |
Curiosidades e bastidores da discussão
Durante o debate na LKML, ficou claro que a exigência de que uma divisão de página “nunca pudesse falhar” era um conservadorismo que custava caro ao hardware moderno. David Hildenbrand, um dos revisores proeminentes, apontou que a maioria das operações que engatilham um split (como mprotect ou munmap) já possuem caminhos de tratamento para falhas de alocação.
O patch também realiza uma limpeza significativa no código. O sistema de depósito e retirada de tabelas de páginas tornou-se código morto para quase todas as arquiteturas, como x86 e ARM64. A única exceção notável é a arquitetura PowerPC quando utiliza tabelas de hash MMU, que ainda requer o depósito antecipado devido a restrições específicas de hardware. Por esse motivo, o código antigo foi mantido apenas como um “stub” para arquiteturas que não precisam dele.
Quando isso chega no meu PC?
Os patches foram baseados na branch mm-unstable e estão em processo de integração para o ciclo estável do Kernel Linux 7.0-rc1. Seguindo o fluxo normal de desenvolvimento, a funcionalidade deve ser consolidada na versão final do Kernel Linux 7.0. Usuários de distribuições de lançamento contínuo (rolling release) devem receber a novidade em meados de 2026, enquanto distribuições corporativas como RHEL e Ubuntu LTS devem incluir a otimização em suas próximas grandes atualizações de ciclo de vida.
