Se você já mexeu com Transparent Huge Pages (THP), sabe: grandes blocos de memória reduzem falhas de página e aliviam a pressão na TLB. A novidade agora é o Linux mTHP support, que ensina o daemon khugepaged a “juntar” páginas normais em páginas enormes de múltiplos tamanhos (não só 2 MB), escolhendo na hora o melhor encaixe para cada região de memória. Resultado? Mais flexibilidade, menos desperdício e ganhos consistentes em cargas de trabalho reais. Veja a proposta técnica da série de patches do Nico Pache em [mTHP support].
O que muda na prática?
Antes, o khugepaged só colapsava para o tamanho “clássico” de THP (nível PMD, geralmente 2 MB). Com mTHP, ele passa a considerar várias ordens (tamanhos) e colapsa apenas a parte útil de um intervalo — sem precisar esperar o bloco inteiro ficar “perfeito”. Esse comportamento é descrito na documentação e no patch de atualização do guia do administrador (transhuge.rst) que acompanha a série.
Por que isso importa?
- Melhor aproveitamento de memória: nem sempre há 2 MB “redondos” e quentes para promover. Com mTHP, você ganha encaixes intermediários.
- Menos page faults e TLB misses: páginas maiores reduzem a contagem de entradas necessárias para mapear a mesma área. Em cargas como Redis e bancos de dados, isso frequentemente vira latência menor. A base técnica está detalhada no patch [00/13] e na discussão da v9/v10.
- Compatível com o que você já faz: quando mTHP não estiver habilitado, o comportamento legado do khugepaged é preservado (só PMD). Isso está explícito na série.
Como o kernel decide o “tamanho ideal”
O khugepaged passa a varrer o intervalo de uma PMD e manter um bitmap por “pedaços” menores. Depois, usa um algoritmo (uma recursão binária em cima do bitmap) para escolher a maior ordem viável naquele trecho — e só então tenta colapsar. Essa mecânica aparece descrita como collapse_scan_bitmap nas discussões e diffs da série.
Um detalhe importante: para mTHP (ordens abaixo de PMD), o khugepaged evita colapsar quando encontra páginas compartilhadas ou swap — isso previne “promoções em cascata” indesejadas no próximo ciclo. A documentação atualizada também orienta sobre isso.
Evitando o “creep” (promoção infinita)
Habilitar vários tamanhos ao mesmo tempo pode criar um efeito “escada”: você colapsa em um tamanho, traz páginas novas, e no próximo scan o algoritmo tenta promover para um tamanho ainda maior — repetidamente. O time propõe um ajuste simples: baixar max_ptes_none (por exemplo, ≤ 255 em páginas base de 4 KB) para reduzir esse impulso de promoção contínua. A orientação aparece no patch de documentação de transhuge.
Métricas e visibilidade (por ordem)
A série também inclui novas métricas por ordem — por exemplo, contadores de alocações de colapso bem-sucedidas e falhas (collapse_alloc / collapse_alloc_failed) e estatísticas de “excedeu none/swap/shared” durante tentativas de mTHP. Isso facilita observabilidade e tuning fino em produção. Veja os patches que introduzem e documentam esses contadores.
Dica de operação
- Monitore as novas métricas por ordem e tracepoints ao validar mTHP no seu ambiente. A documentação oficial do Transparent HugePage Support foi atualizada e serve como referência de primeira parada.
Compatibilidade e caminho de upstream
Além do trabalho do Nico Pache, há revisões e acks de mantenedores e colaboradores ativos em mm/. O tópico já apareceu em threads com Andrew Morton e recebeu encaminhamento para integração nos fluxos do mm-tree, indicando maturidade do recurso. Para acompanhar o status, consulte a thread principal e as respostas na lista.
Quem ganha com isso?
- Caches in-memory (ex.: Redis): melhor relação entre footprint e TLB, com menos variação de latência em picos. Base técnica e motivação estão bem detalhadas na própria [série de patches].
- Bancos de dados e OLTP: queda de page faults de fundo em páginas “quase cheias”, que antes não eram promovidas.
- Runtimes de linguagem (Java, Go, Python): heaps grandes e fragmentados se encaixam melhor em ordens intermediárias.
Como ativar (resumo rápido)
- Habilite ordens de mTHP apropriadas para anônimos no seu perfil (ex.:
always/madvise/inherit), conforme o guia transhuge. - Ajuste
max_ptes_nonepara um valor baixo (p. ex., ≤ 255 em 4 KB) para evitar creep; monitore os contadores por ordem durante os testes. A recomendação oficial está no patch de documentação. - Observe tracepoints e vmstats introduzidos pela série (incluindo falhas/sucessos de colapso). Consulte os patches de métricas.
Em poucas palavras: o Linux mTHP support dá ao khugepaged um novo mapa mental da memória — ele enxerga tamanhos diferentes e escolhe o que mais compensa agora. Isso transforma THP de “tudo ou nada” em “tudo que fizer sentido”, com ganhos reais em eficiência e previsibilidade. Para detalhes técnicos e tuning, a thread oficial e a documentação atualizada são as melhores fontes.
