virtual-memory-paging-and-tlb

仮想メモリ、ページング、TLB

目的

仮想メモリについて説明します。ページング、マルチレベルページテーブル、TLB の役割、ページフォルト、アドレス変換を取り上げ、OS カーネル、組み込み MPU、パフォーマンス分析をつなぎます。

使用する場面

• mmap、brk、デマンドページングについて理解するとき
• セグメンテーションフォルトやガードページをデバッグするとき
• Huge page や TLB 負荷を調整するとき
• Cortex-M MPU とフル MMU システムを比較するとき

ワークフロー

1. 変換の概要

Virtual address (VA)
├── TLB lookup → physical on hit
└── TLB miss → page table walk → fill TLB
        ├── valid PTE → physical address
        └── invalid → page fault (OS handles)

2. ページテーブル（x86-64 の 4 レベルの例）

CR3 → PML4 → PDPT → PD → PT → physical frame

x86_64 上の Linux では、デフォルトで 4 KiB ページを使用し、オプションで 2 MiB／1 GiB の Huge page を使用できます。

3. ページフォルトの種類（簡易版）

フォルト	典型的な原因
メジャー	ディスク読み込み — ファイルバックのページが RAM にない
マイナー	ゼロフィルまたは COW の分離
保護	カーネルページへのユーザーアクセス、W^X 違反

# Linux page fault stats
grep pgfault /proc/vmstat

4. TLB 負荷

大規模で疎なアドレス空間でランダムにポインターをたどると、TLB ミスが支配的になります。

緩和策：

• Huge page の mmap（MAP_HUGETLB、madvise(MADV_HUGEPAGE)）
• ワーキングセットを小さくする／局所性を高める
• NUMA では numactl --membind

5. 組み込みとの比較（Cortex-M）

多くの MCU はフルページングではなく、領域ベースの MPU を使用します。TLB はなく、領域数も固定です。アプリケーションプロセッサは MMU と OS を使用します。

Sv39／Sv48 については skills/platform/riscv-privileged を参照してください。

6. ユーザー空間からの確認（Linux）

cat /proc/self/maps
pmap -x $$

7. エージェントの使用方法

/virtual-memory-paging-and-tlb Explain why 4 KiB random access hurts TLB and hugepage helps

よくある問題

症状	原因	解決策
セグメンテーションフォルト	マッピングされていない VA	ポインターを修正し、maps を確認する
mmap ワークロードが遅い	TLB スラッシング	Huge page を使う。領域数を減らす
fork 後の COW スパイク	書き込み時に共有ページが分割される	想定どおりです。MAP_POPULATE を検討してください
W^X フォルト	mprotect の切り替えを行わない JIT	RW と RX のマッピングを分ける
MCU で物理アドレスが誤っている	MMU がなく、リニアマッピングになっている	リンカースクリプトのアドレスを使用する

関連スキル

• skills/computer-architecture/memory-hierarchy-and-caches — 変換後のキャッシュ
• skills/kernel-dev/kernel-memory-management — カーネルのページアロケーター
• skills/kernel/os-dev-scratch — ページングをゼロから構築する
• skills/platform/riscv-privileged — Sv39 ページテーブル
• skills/allocators/numa-programming — NUMA と移行