前幾篇談到 page fault、demand paging 和 copy-on-write，都會在需要時向 kernel 取得新的 physical page。但實體記憶體不是一疊可以隨意抽取的紙張：kernel 必須追蹤哪些 page 可用、哪些已被占用，也要能快速找出一段連續的 pages。Linux 處理這項工作的核心機制之一，就是 buddy allocator。

Buddy allocator 以 page 為最小管理單位，並依 2 的次方將連續的閒置 pages 分組。order 0 代表 1 個 page，order 1 代表 2 個連續 pages，order 2 代表 4 個，依此類推。每個記憶體 zone 都有不同 order 的 free list，配置時便從能容納需求的最小 order 開始尋找。

假設 kernel 需要 2 個連續 pages，但 order 1 的 free list 已經沒有合適區塊。allocator 可以從較高的 order 取出一個區塊，把它對半拆分；其中一半用來滿足配置，另一半放回較低 order 的 free list。若取到的是 order 3 區塊，它會先拆成兩個 order 2，再把其中一個 order 2 拆成兩個 order 1。

釋放時則反向處理。每個區塊都有一個由位址計算出的 buddy；兩者大小相同，而且在上一層原本屬於同一個連續區塊。如果 buddy 也處於閒置狀態，allocator 就把兩者合併成更高 order 的區塊，並持續嘗試向上合併。這也是 buddy allocator 名稱的由來。

拆分與合併讓配置速度相對可預測，也能降低外部碎片，但不能消除碎片。系統可能仍有很多閒置 pages，卻分散在不同位置，無法組成高 order 的連續區塊。此時 order 0 配置或許能成功，需要大量連續 pages 的配置卻可能失敗。kernel 會藉由 memory compaction 嘗試搬移可移動的 pages，整理出連續空間。

實際系統還有 NUMA node 與 zone 的限制。DMA、DMA32、Normal 等 zone 服務不同的位址能力；NUMA 系統則希望優先從靠近 CPU 的 node 配置。配置請求也會帶著 GFP flags，表達是否能睡眠、能否啟動回收，以及可使用哪些記憶體範圍。因此一次配置並不是只看 order，還要同時考慮 node、zone、水位與配置情境。

可以從 /proc/buddyinfo 觀察各 node、zone 在每個 order 還有多少閒置區塊。例如某欄數值很高，表示該 order 有許多連續區塊；高 order 長期接近零，則可能代表實體記憶體已經碎片化。不過這份資料是即時快照，判讀時要搭配 workload、記憶體壓力和配置失敗紀錄。

一般應用程式的 malloc() 不會直接逐次呼叫 buddy allocator。使用者空間 allocator 先管理自己的 heap；kernel 內部的小物件也通常交給 slab 或 SLUB allocator。Buddy allocator 位在更底層，負責供應 page 級區塊。下一篇會接著看 SLUB 如何利用這些 pages，高效率管理大量且大小固定的 kernel objects。