このドキュメントは疑問に思っていた点をAIエージェントとの対話を通じて整理したメモです。仮想アドレスが物理アドレスに変換されるフローを基準に、MMU、TLB、ページテーブル、page faultを整理します。
仮想アドレスはどのように物理アドレスになるのか？#
TLB / MMU / OSメモリ管理者（MMS）
目次#
1. MMUとTLBの役割と違い#
全体像 — ハードウェア構造#
CPU
┌─────────────────────────────────────┐
│ ALU / Register / Control Unit │
│ │
│ ┌─────────────────────────────┐ │
│ │ MMU │ │
│ │ ┌───────────────────────┐ │ │
│ │ │ TLB (変換キャッシュ) │ │ │
│ │ └───────────────────────┘ │ │
│ │ ページテーブルウォークロジック │ │
│ └─────────────────────────────┘ │
│ │
│ ┌───────────────┐ │
│ │ L1/L2 Cache │ │
│ └───────────────┘ │
└──────────────┬──────────────────────┘
│ 物理アドレス
▼
[ RAM (DRAM) ]MMUはCPU側のハードウェアアドレス変換ユニットだ。
説明の便宜上「CPUとメモリの間」と言うことがあるが、実際にはCPUに統合されたアドレス変換ハードウェアと理解する方が近い。
TLBはその中で最近の変換結果をキャッシュする小さなハードウェアキャッシュだ。
2. ページングシステムとページテーブルの問題#
ページサイズを小さくすると？#
非連続なメモリ割り当てポリシーでページングシステムを使う場合、
ページサイズを小さくすると内部断片化は減るがページテーブルが巨大になる問題が発生する。
計算例#
以下は32bitアドレス空間、4KBページ、エントリ4byte、単一レベルページテーブルを単純に仮定した計算だ。
32bitアドレス空間、4KBページ基準
→ ページ数 = 2^32 / 2^12 = 2^20 = 約100万エントリ
→ エントリ1つあたり4byte → ページテーブル1つ = 4MB
→ プロセス100個 = 400MBがページテーブルだけで消費現代のシステムはアドレス空間がより大きく、実際には使用していない区間も多い。
そのため階層型（多段階）ページテーブルを使用してページテーブルのメモリ無駄を減らす。
パフォーマンス問題 — page table walkのコスト#
ページテーブル自体はメモリにある。
したがってTLB missが発生するとMMUはpage table walkを実行して必要なエントリを読み込む必要がある。
- 単一レベルのテーブルのみを仮定すると「ページテーブル1回 + 実際のデータ1回」のように説明できる。
- しかし現代のCPUは多段階ページテーブルを使うため、TLB miss時に追加のメモリ参照が必要になる場合がある。
- 実際のコストはCPU cache、page walk cacheの有無によって変わる。
つまり核心は**「メモリアクセスが常に正確に2倍」**ではなく、
**「TLB missはコストが高く、だから変換キャッシュが重要だ」**という点だ。
3. TLB (Translation Lookaside Buffer)#
役割#
最近使用された仮想アドレス → 物理アドレス変換結果をキャッシュするハードウェアキャッシュ。
動作フロー#
CPUが仮想アドレスを生成
│
▼
┌───────────┐
│ TLB参照 │──── TLB Hit ──→ 物理アドレスを即時返却
└───────────┘
│ TLB Miss
▼
MMUがPage Table Walkを実行
（メモリにあるページテーブルを巡回）
│
▼
物理アドレスを取得 → TLBに保存 → 返却TLBの特徴#
| 項目 | 内容 |
|---|---|
| 保存対象 | 最近使用した仮想アドレス → 物理アドレス変換結果 |
| 位置 | MMUが活用する小さなハードウェア変換キャッシュ |
| サイズ/構造 | 実装依存。一般的に非常に小さく高速 |
| 効果 | page table walkを減らしてアドレス変換の遅延を下げる |
実装によってはinstruction TLB / data TLBが分離されていたり、
複数段階のTLBが存在する場合もある。
TLBが効果的な理由#
時間的局所性 + 空間的局所性のおかげだ。
同じページや隣接するページへの繰り返しアクセスパターンが多いため、
非常に小さな変換キャッシュだけでもpage table walkを大幅に減らすことができる。
4. Context Switch時のTLB#
プロセスやアドレス空間が変わると、既存のTLBエントリをそのまま使えない状況が生まれる。
ただしこのとき常に全TLBをflushしなければならないわけではない。
2つの処理方式#
| 方式 | 説明 | デメリット |
|---|---|---|
| TLB Flush | アドレス空間切り替え時に関連エントリを削除 | 切り替え直後にTLB missが増える |
| ASID (Address Space ID) | TLBエントリにアドレス空間識別子をタグ付け | 識別子数と管理ポリシーの制約がある |
つまり、アドレス空間の切り替え = 必ず全TLBの初期化と覚えるより、
アーキテクチャがアドレス空間識別子をサポートするかどうかによってflush戦略が変わると理解する方が正確だ。
5. MMU vs TLBの一行まとめ#
| MMU | TLB | |
|---|---|---|
| 役割 | アドレス変換全体を担当 | よく使う変換結果のキャッシュ |
| 位置 | CPUのアドレス変換ハードウェア | MMUが活用する変換キャッシュ |
| 実装の性格 | table walk、権限チェック、fault発生などを含む | 実装依存の小さなオンチップキャッシュ |
| なければ | 仮想アドレスを物理アドレスに自動変換しにくい | page table walkのコストが増えてパフォーマンス低下 |
結論： MMUはアドレス変換という機能全体を担うユニットであり、
TLBはその中でパフォーマンスのボトルネックを解決するために存在するキャッシュコンポーネントだ。
TLBはMMUの一部として理解すればよい。
6. OSメモリ管理者（MMS）#
標準用語の整理#
「MMS」はLinux/Windowsの公式ドキュメントで代表的な標準略語として広く使われるというよりも、
文脈上OSのメモリ管理サブシステムを指す表現として理解する方が安全だ。
- Linuxは通常Memory Management（MM）またはVM subsystemの文脈で説明する。
- WindowsはMemory Managerという名称を使う。
ハードウェア vs ソフトウェアのメモリ管理の区分#
[ プロセス ] → 仮想アドレスを生成
│
▼
[ MMU / TLB ] ← ハードウェア
アドレス変換担当
│
│ Page Fault発生時に例外
▼
[ OSメモリ管理者 ] ← ソフトウェア、カーネル内部
ページテーブル管理、ページ置き換え、スワップ、fault処理担当
│
▼
[ 物理メモリ（RAM）+ スワップ領域（ディスク）]OSメモリ管理者が行うこと#
1. ページテーブルの作成と管理#
- プロセスごとのアドレス空間に合わせてページテーブルを作成・維持する。
- 一般的な汎用OSではOSまたはハイパーバイザーがテーブルを管理し、MMUはその結果を使って変換を実行する。
2. Page Faultの処理#
- MMUが非常駐ページやアクセス権限違反などの条件でpage fault例外を発生させる場合がある。
- OSはその原因を確認してページをロードするか、権限エラーなら例外を伝えるかプロセスを終了させる。
- 正常な場合はページテーブルを更新した後、命令を再実行させる。
3. スワップ（Swap）管理#
- 物理メモリが不足すると、どのページをディスクに退避させるかを決める。
- ページ置き換えアルゴリズムを使ってメモリの圧迫を緩和する。
- この部分はパフォーマンスに大きな影響を与えるOSのポリシー領域だ。
4. メモリ割り当て（malloc、mmap）の背後#
- ユーザープログラムがメモリを要求したとき、カーネルは仮想アドレス空間を確保してマッピングポリシーを決める。
- 実際の物理フレームの割り当ては最初のアクセス時点まで遅らせる場合がある。これがdemand pagingの文脈だ。
5. 共有メモリ / Copy-on-Write（CoW）#
fork()のような操作では、最初からすべてのページをコピーせずに共有できる。- その後どちらかが書き込みを試みたときだけコピーして、メモリの無駄を減らす。
OS別メモリ管理者の名称#
| OS | メモリ管理者の名称 |
|---|---|
| Linux | MM subsystem / VM subsystem（mm/） |
| Windows | Memory Manager（Mm、MmXxx関数群） |
Linuxカーネルソースの
mm/ディレクトリにはpage_alloc.c、swapfile.c、mmap.cのようなコードが入っている。
MMU vs OSメモリ管理者の比較#
| MMU | OSメモリ管理者 | |
|---|---|---|
| 種類 | ハードウェア | ソフトウェア（カーネル） |
| 役割 | アドレス変換の実行、権限チェック、faultシグナル | 変換規則（ページテーブル）の作成、置き換え/スワップポリシーの決定、fault処理 |
| 時間特性 | メモリアクセス経路の非常に高速なハードウェア処理 | fault発生時のはるかに重いカーネル処理 |
| 比喩 | 通訳者 | 通訳者に辞書とルールを提供する人 |
核心まとめ：
MMUは**メカニズム（Mechanism）を担当し、
OSメモリ管理者はポリシー（Policy）**を担当する。
参考資料#
- Arm Learn the Architecture - Memory management: https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/LearnTheArchitecture-MemoryManagement-101811_0100_00_en.pdf
- Linux Kernel Documentation - Page Tables: https://docs.kernel.org/6.9/mm/page_tables.html
- Linux Kernel Documentation - Cache and TLB Flushing Under Linux: https://www.kernel.org/doc/html/latest/core-api/cachetlb.html
- Intel - Machine Check Error Avoidance on Page Size Change: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/machine-check-error-avoidance-on-page-size-change.html
- Microsoft Learn - Windows kernel-mode memory manager: https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/windows-kernel-mode-memory-manager