メインコンテンツまでスキップ

コラム: なぜページサイズは4KBなのか

読了時間: 5分

4KBの起源: Intel 386​

1985年、Intel 80386プロセッサが登場しました。このプロセッサで初めて本格的な仮想メモリがx86アーキテクチャに導入され、ページサイズは 4KB（4,096バイト） に決定されました。

なぜ4KBだったのでしょうか？

当時のトレードオフ​

ページサイズの決定には、2つの相反する要素がありました。

┌─────────────────────────────────────────────────────────────────────┐
│                    ページサイズのジレンマ                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  小さいページ（例: 1KB）                                            │
│  ├── メリット: 内部フラグメンテーションが少ない                     │
│  └── デメリット: ページテーブルが巨大になる                         │
│                                                                      │
│  大きいページ（例: 64KB）                                           │
│  ├── メリット: ページテーブルが小さい、TLB効率が良い                │
│  └── デメリット: メモリの無駄が多い                                 │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

1985年当時の状況​

  • メモリ: 1〜4MB程度が一般的
  • ディスク: 20〜40MB程度
  • メモリは非常に高価

この時代、メモリの無駄は致命的でした。64KBページでは、小さなプログラムでも大量のメモリを消費してしまいます。

なぜ「4KB」という数字なのか​

2のべき乗​

4KB = 4,096 = 2^12

コンピュータは2進数で動作するため、2のべき乗はアドレス計算が効率的です。

仮想アドレス（32ビット）:
┌────────────────────┬────────────────────┐
│  上位20ビット      │   下位12ビット      │
│  ページ番号        │   ページ内オフセット │
└────────────────────┴────────────────────┘

12ビット = 4,096 通り = 4KB

ディスクセクタとの相性​

当時のハードディスクは512バイトセクタが標準でした。

4KB = 512バイト × 8セクタ

ページサイズがセクタサイズの倍数であることで、ディスクI/Oが効率的になります。

ページテーブルのサイズ​

32ビットアドレス空間（4GB）を4KBページで管理する場合：

4GB ÷ 4KB = 1,048,576 ページ
= 約100万エントリ

1エントリ = 4バイトとすると
ページテーブル = 4MB

これは当時のメモリ量からすると大きいですが、階層化ページテーブルで解決できる範囲でした。

40年後の今、なぜ変わらないのか​

386から40年経った今でも、多くのシステムが4KBページを使い続けています。

互換性の壁​

┌─────────────────────────────────────────────────────────────────────┐
│                    4KBに依存するもの                                 │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ・アプリケーション（mmap のアライメント前提）                      │
│  ・共有ライブラリ（ELFのセクションアライメント）                    │
│  ・ファイルシステム（ブロックサイズ）                               │
│  ・データベース（ページサイズ）                                     │
│  ・仮想化ソフトウェア                                               │
│  ・無数のシステムコール                                             │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

この膨大なエコシステムを変更するコストは計り知れません。

Huge Pages という妥協案​

Linuxは完全移行ではなく、Huge Pages という仕組みを導入しました。

通常ページ:     4KB
Huge Pages:    2MB または 1GB

大量のメモリを使うアプリケーション（データベース、JVMなど）は、明示的にHuge Pagesを使うことでTLB効率を改善できます。

# Huge Pages の確認
$ cat /proc/meminfo | grep Huge
HugePages_Total:       0
HugePages_Free:        0
Hugepagesize:       2048 kB

Android 16KBへの移行​

2024年、Androidは16KBページサイズのサポートを開始しました。

なぜ今、変更できたのか​

┌─────────────────────────────────────────────────────────────────────┐
│                    Android が移行できた理由                          │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  1. 比較的新しいエコシステム                                        │
│     └── PC/サーバーほど互換性の負債がない                          │
│                                                                      │
│  2. Google の統制力                                                  │
│     └── Play Store 要件で強制できる                                 │
│                                                                      │
│  3. ARM64 の柔軟性                                                   │
│     └── 4KB/16KB/64KB をサポート                                    │
│                                                                      │
│  4. メモリの大容量化                                                │
│     └── フラグメンテーション増加を許容できる                       │
│                                                                      │
│  5. 性能要求の高まり                                                │
│     └── TLB ミス削減の効果が大きい                                  │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

期待される効果​

  • 全体性能: 5〜10%向上
  • アプリ起動: 平均3%高速化
  • TLBミス: 大幅削減

まとめ​

4KBページサイズは、1985年のハードウェア制約とソフトウェア要件のバランスから生まれました。

4KB = 2^12
    = ディスクセクタ × 8
    = 当時のメモリ効率とテーブルサイズの妥協点

40年経った今でも使われ続けているのは、技術的に最適だからではなく、変更コストが高すぎるからです。

Androidの16KB移行は、モバイル特有のエコシステムと強力なプラットフォーム統制があって初めて実現できた、稀有な例と言えるでしょう。

参考​