Linux HugeTLBと透過的Huge Page：TLBの利点と運用上のトレードオフ

アドレス変換でTLBが担う役割

プロセスの仮想アドレスはページテーブルを通じて物理メモリへ変換されます。CPUは最近の変換結果をTLB（変換索引バッファ）に保持し、同じ情報を毎回ページテーブルから探す負担を抑えます。大きなメモリ領域にアクセスするワークロードでは、小さなページほど多くの変換情報が必要になり、TLBに保持しきれない場合があります。大きなページは一つの変換がカバーする範囲を広げ、この負担を減らす可能性があります。ただし効果はCPU、ページサイズ、アクセスパターン、仮想化の有無で異なり、ページ比率だけからアプリ全体の速度向上を予測できません。

HugeTLBは大きなページをプールに予約する

Linuxカーネル文書はHugeTLBの総数、空き、予約、超過ページを/proc/meminfoやsysfsで確認できると説明しています。管理者は起動時または稼働中にページ数を設定できますが、対応するサイズはアーキテクチャによって異なります。カーネル文書にある2 MiBや、対応環境での1 GiBは例であり、すべてのCPUに共通する値ではありません。予約されたメモリは通常の割り当てに使えず、HugeTLBページはメモリ圧迫時にもスワップアウトされません。したがって過大な予約は、他の処理が使えるメモリを減らします。

プール確保には物理的に連続した空きメモリが必要です。起動時の予約は断片化前に大きな領域を見つけやすくする一方、実行中の確保はその時点のメモリ状態に左右されます。NUMAポリシーも、どのノードからページを確保するかに影響します。空きページ数が表示されていても、アプリがhugetlbfs、MAP_HUGETLB、共有メモリなど対応する方法で要求しなければ利用しているとは限りません。

THPはカーネルがマッピングを動的に管理する

透過的Huge Page（THP）は、固定プールを事前予約しなくてもカーネルがマッピングを昇格・分割できる仕組みです。現在のカーネル文書は、基本ページより大きく従来のPMDサイズより小さい複数サイズTHPも扱っています。使用できるページサイズやメモリ種別は、CPUとカーネルに依存します。khugepagedは条件を満たす領域を走査して基本ページをまとめることがあり、設定はシステム全体だけでなく特定プロセスやアドレス範囲にも限定できます。

自動管理でも処理コストがなくなるわけではありません。大きなマッピングの作成、分割、ページ移動にはメモリ処理が伴い、広い領域の一部しか使わないアプリでは、必要以上のメモリを消費する場合があります。一方、大きな作業セットでは変換回数やページフォールトの減少が役立つことがあります。結果はワークロード次第で、THPが常に有利とも不利とも言えません。

専門家の視点：設定例は性能保証ではない

Red Hat Enterprise Linux 10の文書は、予約型HugeTLBとTHPのシステム全体・プロセス別設定を分けて説明しています。起動時予約は断片化前に大きな連続領域を得やすくする可能性がありますが、具体例は対象システムに合わせる必要があると同章は明記しています。この資料から、あらゆるデータベースでTHPを無効にすべき、あるいは静的HugeTLBなら必ず高速になるとは結論できません。

比較するなら、実際のCPUとカーネル、対応ページサイズ、アプリのマッピング方式、NUMA配置、メモリ余力を確認します。設定を試すときは同じ負荷と測定時間で、レイテンシ分布、メモリ使用量、ページフォールト、利用可能なTLB関連指標を変更前後で比べて記録します。一台のサーバーで得た結果を、別のアプリや環境にも当てはまる保証として紹介しないことが重要です。

出典

• Linux Kernel Documentation, “HugeTLB Pages” — プール状態、ページサイズ、NUMA・連続メモリの制約、利用方法に関するカーネル文書。
• Red Hat, “Chapter 12. Configuring huge pages” — RHEL 10におけるHugeTLB予約とTHP設定の違いを説明する製品文書。