Linux mTHP support: khugepaged fica mais esperto — e seu servidor agradece

Huge pages do tamanho certo, na hora certa.

Escrito por
Emanuel Negromonte
Emanuel Negromonte é Jornalista, Mestre em Tecnologia da Informação e atualmente cursa a segunda graduação em Engenharia de Software. Com 14 anos de experiência escrevendo sobre...

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)

  1. Habilite ordens de mTHP apropriadas para anônimos no seu perfil (ex.: always/madvise/inherit), conforme o guia transhuge.
  2. Ajuste max_ptes_none para 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.
  3. 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.

Compartilhe este artigo