夥伴系統和slab記憶體分配機制詳解

當在使用者模式下執行進程請求額外記憶體時，從核心維護的空閒頁幀列表上分配頁面。這個列表通常使用頁面置換演算法來填充，如前所述，它很可能包含散布在實體記憶體中的空閒頁面。也要記住，如果使用者進程請求單個位元組記憶體，那麼就會導致內部碎片，因為進程會得到整個幀。

用於分配核心記憶體的空閒記憶體池通常不同於用於普通使用者模式進程的列表。這有兩個主要原因：

1. 核心需要為不同大小的資料結構請求記憶體，其中有的小於一頁。因此，核心應保守地使用記憶體，並努力最小化碎片浪費。這一點非常重要，因為許多作業系統的核心程式碼或資料不受調頁系統的控制。
2. 使用者模式進程分配的頁面不必位於連續實體記憶體。然而，有的硬體裝置與實體記憶體直接互動，即無法享有虛擬記憶體介面帶來的便利，因而可能要求記憶體常駐在連續實體記憶體中。

下面討論兩個策略，以便管理用於核心進程的空閒記憶體：“夥伴系統”和 slab 分配。

夥伴系統

夥伴系統從物理連續的大小固定的段上進行分配。從這個段上分配記憶體，採用 2 的冪分配器來滿足請求分配單元的大小為 2 的冪（4KB、 8KB、16KB 等）。請求單元的大小如不適當，就圓整到下一個更大的 2 的冪。例如，如果請求大小為 11KB，則按 16KB 的段來請求。

讓我們考慮一個簡單例子。假設記憶體段的大小最初為 256KB，核心請求 21KB 的記憶體。最初，這個段分為兩個夥伴，稱為 A_L 和 A_R，每個的大小都為 128KB；這兩個夥伴之一進一步分成兩個 64KB 的夥伴，即 B_L 和 B_R。然而，從 21KB 開始的下一個大的 2 的冪是 32KB，因此 B_L 或 B_R 再次劃分為兩個 32KB 的夥伴 C_L 和 C_R。因此，其中一個 32KB 的段可用於滿足 21KB 請求。這種方案如圖 1 所示，其中 C_L 段是分配給 21KB 請求的。

---