O fim de uma era: desenvolvedores do kernel Linux buscam consenso para finalmente remover o suporte ao HIGHMEM

Uma das funcionalidades mais antigas — e, nas palavras de Arnd Bergmann, “uma das menos populares” — do Linux está na berlinda. Em um tópico técnico na LKML, Arnd Bergmann propôs que a comunidade alcance um consenso para iniciar um phase-out do CONFIG_HIGHMEM, com um plano de dois anos para reduzir gradualmente o uso e, depois, remover de vez o mecanismo de “memória alta” introduzido ainda em 1999. Não é pouca coisa: estamos falando de um pilar que permitiu a sobrevivência de máquinas 32-bit por décadas.

O que é HIGHMEM e por que aposentá-lo?

Pense no kernel 32-bit como um mapa que só enxerga um bairro pequeno: o lowmem (aprox. 1 GB). Se a sua “casa” (RAM) fica fora desse bairro — a highmem — o kernel não consegue acessá-la diretamente. Para entrar e sair, ele abre portais temporários com kmap()/kunmap(): usa, fecha o portal, abre de novo… e assim por diante. Esse vai-e-vem tem custo: complica a árvore de código, alonga o caminho de falha de página e é terreno fértil para bugs sutis. Em arquiteturas 32-bit, a fatia de lowmem disponível costuma ficar em torno de ~892 MiB; o restante (acima de ~896 MiB) vira HIGHMEM — daí a necessidade de “portais”.

Se em 1999 isso foi um truque engenhoso, em 2025 o contexto mudou radicalmente. Máquinas 64-bit dominaram o mundo e o que resta de 32-bit — com raras exceções — roda aplicações modestas ou sistemas embarcados de ciclo muito longo. Resultado: manter o HIGHMEM hoje significa carregar complexidade técnica que afeta caminhos críticos (page fault, pagecache, metadados de FS) para beneficiar uma minoria cada vez menor de dispositivos.

Quem ainda depende disso?

Bergmann fez um raio-x honesto do cenário atual. Em desktops e laptops 32-bit “tardios” (Pentium 4 “Northwood”, Core Duo) até houve configurações com 2 GB+, mas essas linhas desapareceram do suporte oficial dos próprios sistemas originais e da maioria das distros Linux. O uso “vivo” concentra-se no mundo embarcado, sobretudo em ARMv7 — com especial destaque para o i.MX6 Dual/Quad, extremamente popular e com suporte do fabricante garantido até 2035. É aí que a proposta pisa com mais cuidado.

Para placas ARMv7 com 1 GB de RAM, a aposta de Bergmann é que quase tudo funciona bem ao migrar para CONFIG_VMSPLIT_3G_OPT (passando a ter 1 GB de lowmem e ~2816 MB de espaço de usuário), eliminando a necessidade de HIGHMEM sem traumas. Já nos casos com 2 GB, como muitos i.MX6, a saída é testar CONFIG_VMSPLIT_2G ou CONFIG_VMSPLIT_2G_OPT, avaliando cuidadosamente aplicações que exigem grande endereço virtual (p.ex., Firefox embarcado). Há, ainda, SoCs com mapeamentos físicos esparsos (Renesas R-Car Gen2, Broadcom BCM4708) que precisam de ajustes no sparsemem antes da transição.

E as exceções curiosas? Há plataformas MIPS (como MT7621 e JZ4780), PowerPC de linhas 85xx/86xx/QorIQ e até sparc32/LEON que, por design, convivem com limites de lowmem bem apertados. O ponto de Bergmann, porém, é pragmático: mesmo nesses casos, a tendência é de redução de uso ativo e/ou de migração para kernels LTS específicos quando a remoção finalmente ocorrer no mainline.

O plano de aposentadoria de dois anos

Em vez de um “big bang”, a proposta de Arnd Bergmann é iterativa e com marcos bem definidos:

1. Rebaixar o CONFIG_HIGHMEM para depends on EXPERT, atualizando a descrição para refletir a discussão e as decisões do Kernel Summit.
2. Mudar os defaults do ARMv7 para CONFIG_VMSPLIT_3G_OPT e HIGHMEM=n (e possivelmente fazer o mesmo em x86 e powerpc) para expor regressões cedo, sem quebrar usuários.
3. Remover __GFP_HIGHMEM de alocações no kernel fora do page cache (drivers, metadados de FS etc.).
4. Desativar HIGHMEM em plataformas que claramente não precisam (ARC, ARMv5, PPC4xx/82xx/83xx, C-SKY, Microblaze, Xtensa…), validando a hipótese de que tudo roda apenas em lowmem.
5. Separar o uso de páginas altas no ZRAM em um Kconfig próprio — habilitável sem CONFIG_HIGHMEM.
6. Concluir o “densemem” como alternativa ao sparsemem para permitir lowmem esparsos e seleção do vmsplit em boot (em vez de build-time).
7. Etapa final: remover o page cache em highmem, mantendo acesso a páginas altas apenas via ZRAM e drivers específicos. Essa etapa ficaria para um kernel LTS adequado — Arnd aponta a probabilidade de ser Linux 7.4, previsto para dezembro de 2026, pois alinha com a janela de SLTS do projeto CIP (10 anos).

Em paralelo, Matthew Wilcox sugere um caminho de baixo atrito para começar a colher benefícios já: matar o HIGHPTE — recurso que complicou o caminho de page fault — visto que o x86 já removeu o suporte e só o ARM32 restava. Limpar isso derruba uma parcela imediata de complexidade. O histórico recente corrobora: patches para remover HIGHPTE do ARM e do código comum avançaram entre o fim de 2024 e 2025.

Ecos da comunidade: do pragmatismo ao “museu”

O debate, claro, é plural. H. Peter Anvin lembra que 1 GB era o padrão em boa parte da era 32-bit e que, sem HIGHMEM, sistemas assim perdem memória utilizável — o que exige sensibilidade na transição (ou a opção por permanecer em LTS adequados). Por outro lado, Linus Torvalds foi direto: máquinas desse perfil são “peças de museu”; quem precisa pode muito bem ficar em kernels antigos, enquanto o mainline segue adiante. É uma defesa do pragmatismo evolutivo: simplificar o comum sem impedir quem depende do legado de continuar no trilho via LTS.

David Hildenbrand reforçou o plano em camadas: podar a complexidade onde dói mais (metadados em page cache na highmem, HIGHPTE, __GFP_HIGHMEM fora do essencial) e, ao mesmo tempo, melhorar testabilidade — inclusive explorando ideias para simular cenários de highmem em 64-bit — para não “quebrar silenciosamente” caminhos pouco exercitados. É a manutenção de sempre: medir, isolar, remover, medir de novo.

Por que isso importa (e por que agora)?

No fundo, Linux HIGHMEM virou um custo arquitetural desproporcional frente ao benefício real. Enquanto 64-bit ditam o ritmo de inovação, manter um código especial que mexe com caminhos críticos (faults, pagecache, kmap()), que poucos exercitam e quase ninguém testa, arrasta a complexidade para todo o projeto. A proposta de Bergmann equilibra cautela (defaults que revelam regressões, janela de dois anos, etapa final casada com LTS/SLTS) e ambição (chegar ao ponto em que highmem no page cache não exista no mainline). É “cirurgia” com plano de recuperação.

E para quem ainda precisa? O mapa é claro: migre para VMSPLIT_3G_OPT/2G_OPT quando possível, cuide de aplicações famintas por VA, considere ZRAM “desacoplado” do HIGHMEM e, se nada disso fechar, permaneça em LTS com HIGHMEM por mais tempo. A história do kernel mostra que legados não somem de um dia para o outro — eles são encapsulados, medidos e, quando chega a hora, aposentados com uma trilha segura de suporte.