📖 1. 緒論：4KB 分頁的悖論
在這個個人電腦配備數十 GB 隨機存取記憶體 (RAM)，而資料中心管理著 PB 級資料的時代，一個記憶體管理的基礎單位卻頑固地固定在一個看似古老的尺寸：4 KB。這種持續存在呈現了一個引人注目的悖論。認為在「大記憶體」時代，較大的分頁尺寸會更有效率的直覺並非空穴來風；事實上，硬體容量的指數級增長已對這個數十年的標準施加了巨大壓力。然而，4KB 分頁之所以能持續存在，並非僅僅是個疏忽，而是一個根深蒂固且極具韌性的折衷方案，它平衡了記憶體*空間*效率與位址*轉譯*效率之間的競爭需求。
自 Atlas/Multics 時代 (1960s) 起，4096-byte (≈4KB) 量級的頁 (page) 就已被採用並在後來多數商用與學術系統中演化為實務標準。今天，它仍然是從高效能伺服器到手機甚至手錶等各種運算裝置中最常見的基礎分頁尺寸。儘管許多研究和架構進展已稱此標準為「過時」，但作業系統開發領域的傑出人物也為其辯護，在多數通用負載與相容性需求下，4KB 是一個非常穩定且實用的預設，主要因為它能最大限度地減少因碎片化而造成的記憶體浪費。這種根本性的張力正是使用者問題的核心所在。
核心衝突並非靜態，而是隨著硬體的進步而演變。記憶體管理的中心問題從如何管理稀缺的記憶體轉變為如何有效率地管理豐富的記憶體。
本報告將透過對鞏固 4KB 分頁成為預設標準的各種力量進行詳盡、多層次的分析，來解構這個悖論。最終，本次調查將揭示，4KB 分頁並非一個靜態的遺跡，而是在現代系統設計中一個不斷演進且日益複雜的折衷方案的基礎。
📜 2. 歷史基礎與架構慣性
若不先檢視 4KB 分頁尺寸的起源以及將其鎖定在位的強大慣性力量，就無法理解其持續存在的原因。這是一個「路徑依賴」（path-dependent）技術標準的典型例子。
4KB 的起源
4KB 分頁尺寸的使用早於 x86 架構，深受 1980 年代硬體限制的影響。當時主記憶體稀缺，而硬碟（HDD）是主要儲存媒介。4KB 代表了一個合理的折衷；它足夠大，可以將高昂的磁碟尋道成本分攤到有意義的資料量上，但又足夠小，以避免因內部碎片化而造成過多的記憶體浪費。
嵌入架構（x86）
這個務實的選擇隨後被固化在晶片中。在 IA-32（32 位元 x86）架構中，4KB 成為「基礎分頁尺寸」，一個被硬體的記憶體管理單元 (MMU)辨識和管理的基礎單位。當架構擴展到 64 位元（x86-64）時，這個 4KB 的基礎分頁被保留下來以確保向下相容性。
軟體的慣性
改變基礎分頁尺寸最難以逾越的障礙是建立在「一個分頁是 4KB」這個假設之上的龐大軟體生態系統。這個假設被編織進現代作業系統和應用程式的結構中：
- 作業系統 API： 系統呼叫 (如
mmap()/mprotect()等) 在語義上以「系統頁 (system page) 粒度」運作──在典型 x86 平台該粒度通常為 4KB，但頁大小是由硬體/實作決定；若採用巨頁則需符合該巨頁的對齊/大小要求。 - 編譯器和連結器： 工具鏈依賴 4KB 邊界來排列程式區段和設定記憶體保護。
- 程式設計慣例： 技巧如「哨兵分頁」(guard page) 完全依賴於 4KB 的固定大小來偵測堆疊溢位。
- 檔案系統對齊： 檔案系統區塊與 4KB 記憶體分頁的對齊優化了 I/O 效能。
⚖️ 3. 核心困境：分頁尺寸權衡的多面向分析
決定保留 4KB 分頁作為標準並不僅僅是基於慣性。它是一個複雜且持續的優化問題的結果，是系統設計中多個相互競爭因素之間的一個根本性折衷。
內部碎片化 (Internal Fragmentation)
因為記憶體是以固定大小的區塊（分頁）配置的，配置的最後一個分頁內的未使用空間就被浪費了。分頁越小，浪費越少。
分頁表額外開銷 (Page Table Overhead)
較小的分頁尺寸需要更多的分頁表項目 (PTE)來覆蓋相同的虛擬位址空間，這會消耗更多記憶體來進行簿記。
I/O 效能 (I/O Performance)
較大的分頁尺寸幾乎總是更有效率，因為它們可以將磁碟尋道等高昂的固定成本分攤到更多的資料上。
保護粒度 (Protection Granularity)
較小的分頁尺寸允許對記憶體保護（如唯讀、可寫）進行更細粒度的控制。
優化記憶體額外開銷
總記憶體額外開銷 `O(p)` 可表示為內部碎片化和分頁表開銷之和，其中 `p` 是分頁大小，`s` 是區段平均大小，`e` 是 PTE 大小：
求解此公式可得最小化開銷的最佳分頁大小 `p`：
此計算為早期系統選擇低 KB 範圍的小分頁尺寸提供了強有力的理論依據。
表 1：分頁尺寸選擇的基本權衡
| 指標 | 較小分頁尺寸（例如 4KB） | 較大分頁尺寸（例如 2MB） |
|---|---|---|
| 內部碎片化 | 低。 每次配置浪費的記憶體較少。 | 高。 可能造成嚴重的記憶體浪費。 |
| 分頁表額外開銷 | 高。 需要更多 PTE，消耗更多 RAM。 | 低。 需要的 PTE 較少，節省記憶體。 |
| TLB 效能 | 差。 TLB 覆蓋範圍低，易導致頻繁未命中。 | 優。 TLB 覆蓋範圍高，減少未命中。 |
| I/O 效率 | 較低。 對於循序存取效率較低。 | 較高。 提高吞吐量。 |
| 保護粒度 | 高。 細粒度控制。 | 低。 粗粒度控制。 |
⚡️ 4. 關鍵瓶頸：轉譯旁觀緩衝區 (TLB)
現代電腦中 RAM 的指數級增長已將一個不同的元件推到了討論的最前線：轉譯旁觀緩衝區 (TLB)。TLB，而非 RAM 容量本身，是直接的架構壓力點，使得更大的分頁尺寸不僅僅是一個選項，而是高效能運算的必需品。
TLB 是一個位於 CPU 晶片上的小型、高速的硬體快取，用於儲存最近使用的虛擬到實體位址轉譯。TLB 的有效性由其「覆蓋範圍」決定：
由於 TLB 項目數量無法像 RAM 容量那樣快速增長，增加分頁大小是提高 TLB 覆蓋範圍最直接的方法。例如，一個擁有 2048 個項目的 TLB（示例數字僅示意；實際 TLB 條目與關聯性會因微架構而異）：
- 使用 4KB 分頁：覆蓋範圍 = 2048 × 4 KB = 8 MB
- 使用 2MB 巨量分頁：覆蓋範圍 = 2048 × 2 MB = 4 GB
當應用程式的「工作集」（頻繁存取的記憶體部分）大於 TLB 的覆蓋範圍時，就會發生「TLB 抖動」，導致頻繁且高延遲的分頁表遍歷，嚴重降低效能。增加分頁大小可以直接解決這個問題，這也是引入和使用「巨量分頁」的最重要動機。
🧩 5. 現代的適應：「巨量分頁」的興起
現代電腦系統並未取代 4KB 分頁，而是採用了一種更靈活的混合方法，同時支援多種分頁尺寸。這需要硬體架構和作業系統記憶體管理的協調變革。
硬體支援
x86-64 架構已逐漸支援 2MB 和 1GB 的大型分頁。ARM 架構則提供了更大的靈活性，允許在編譯核心時選擇 4KB、16KB 或 64KB 作為基礎分頁尺寸 (granule)。（註）AArch64 支援 4KB / 16KB / 64KB granule，但哪一個由處理器實作決定，軟體應檢查相關系統寄存器。
表 2：主要作業系統巨量分頁支援比較概覽
| 特性 | Linux | Windows | macOS |
|---|---|---|---|
| 通用名稱 | 巨量分頁 / 透明巨量分頁 (THP) | 大型分頁 | 超級分頁 |
| 機制 | 透明巨量分頁 (THP) 與 hugetlbfs 兩套；系統預設與行為會依發行版/內核版本設定 (always|madvise|never)。 | 明確 (需特權/API 且平台行為不同) | 明確 (需 API 且平台行為不同) |
| 預設行為 | THP 通常為 `madvise` (選擇加入) | 禁用 | 禁用 |
| 主要限制 | THP 可能導致延遲尖峰和記憶體膨脹 | 需要管理權限和應用程式修改 | 易因記憶體碎片化而失敗 |
📊 6. 依賴工作負載的現實
不存在一個普遍「最佳」的分頁尺寸。記憶體存取模式是決定較大分頁尺寸將是效能福音還是禍害的最重要因素。
表 3：工作負載原型與最佳分頁尺寸策略
| 工作負載原型 | 典型存取模式 | 最佳分頁策略 | 理由 |
|---|---|---|---|
| HPC / 科學運算 | 大型、循序、可預測 | 大型分頁 (2MB/1GB) | 最大化 TLB 覆蓋範圍和 I/O 效率。 |
| OLTP 資料庫 | 小型、隨機讀寫 | 小型分頁 (4KB) | 減少鎖競爭，最小化 I/O 浪費。 |
| OLAP / 資料倉儲 | 大型、循序讀取 | 大型分頁 (2MB/1GB) | 最大化掃描吞吐量。 |
| 一般桌面 / 混合使用 | 不可預測的混合 | 小型分頁 (4KB) 為預設 | 最小化內部碎片化，最大化可用記憶體。 |
🔬 7. 分頁管理的未來：超越連續性限制
尖端學術研究正專注於打破一個根本性的連結：為了獲得大型分頁的 TLB 效能，不再需要實體上連續的記憶體。目標是實現大型分頁的效能，而無需付出高昂的實體連續性要求。
Mosaic 分頁 (ASPLOS '23)
提出將大型虛擬分頁對應到多個實體非連續的 4KB 基礎分頁，透過位址壓縮將多個轉譯打包到單一 TLB 項目中，從而 decoupling 虛擬與實體連續性。
靈活分頁管理 (ASPLOS '19)
研究針對分層記憶體系統的高效、原生巨量分頁遷移，使得在不同速度的記憶體層之間移動大型資料區塊變得更加實用和動態。
未來的解決方案將是多管齊下的，標誌著從簡單、靜態的記憶體管理，過渡到一個複雜、動態、由策略驅動的資料協調的新典範。
🏁 8. 結論：一個不斷演進的折衷方案
4KB 分頁尺寸的持續存在並非不合時宜，而是其作為一個非常穩定且有效的折衷方案角色的證明。它被架構慣性的巨大重量以及數十年來的軟體生態所錨定，使其作為基礎標準的延續幾乎是必然的。
解決效能瓶頸的困境並非選擇一種尺寸而捨棄另一種，而是擁抱複雜性。現代系統已演變為同時支援多種分頁粒度。核心問題已從「分頁尺寸應該是多少？」轉變為「作業系統如何為正確的工作負載，在正確的時間，提供正確的分頁尺寸？」
在可預見的未來，4KB 基礎分頁幾乎肯定仍將是記憶體管理的基礎，作為相容性的通用語言和最小化記憶體浪費的預設選擇。效能的未來不在於發現一個新的、靜態的最佳分頁尺寸，而在於完善那些能夠無縫管理多種分頁尺寸的動態、工作負載感知和智慧的機制。4KB 分頁並未過時；它是構建一個更複雜、更智慧的記憶體管理未來的基石。