多年以來，linux 核心使用一種稱為 slab 的核心物件緩衝區分配器。但是，隨著系統規模的不斷增大，slab 逐漸暴露出自身的諸多不足。slub 是 linux 核心 2.6.22 版本中引入的一種新型分配器，它具有設計簡單、**精簡、額外記憶體佔用率小、擴充套件性高，效能優秀、方便除錯等特點。本文先介紹 slab 分配器的基本原理，然後分析其不足之處並詳細介紹 slub 的設計思想，最後介紹 slub 介面 api 函式及物件分配/釋放函式的具體實現。核心物件緩衝區管理
linux 核心在執行過程中，常常會需要經常使用一些核心的資料結構（物件）。例如，當程序的某個執行緒第一次開啟乙個檔案的時候，核心需要為該檔案分配乙個稱為 file 的資料結構；當該檔案被最終關閉的時候，核心必須釋放此檔案所關聯的 file 資料結構。這些小塊儲存空間並不只在某個核心函式的內部使用，否則就可以使用當前執行緒的核心棧空間。同時，這些小塊儲存空間又是動態變化的，不可能像物理記憶體頁面管理使用的 page 結構那樣，有多大記憶體就有多少個 page 結構，形成乙個靜態長度的佇列。而且由於核心無法**執行中各種不同的核心物件對緩衝區的需求，因此不適合為每一種可能用到的物件建立乙個「緩衝池」，因為那樣的話很可能出現有些緩衝池已經耗盡而有些緩衝池中卻又大量空閒緩衝區的現象。因此，核心只能採取更全域性性的方法。
我們可以看出，核心物件的管理與使用者程序中的堆管理比較相似，核心問題均是：如何高效地管理記憶體空間，使得可以快速地進行物件的分配和**並減少記憶體碎片。但是核心不能簡單地採用使用者程序的基於堆的記憶體分配演算法，這是因為核心對其物件的使用具有以下特殊性：
核心使用的物件種類繁多，應該採用一種統一的高效管理方法。
核心對某些物件（如 task_struct）的使用是非常頻繁的，所以使用者程序堆管理常用的基於搜尋的分配演算法比如first-fit（在堆中搜尋到的第乙個滿足請求的記憶體塊）和 best-fit（使用堆中滿足請求的最合適的記憶體塊）並不直接適用，而應該採用某種緩衝區的機制。
核心物件中相當一部分成員需要某些特殊的初始化（例如佇列頭部）而並非簡單地清成全 0。如果能充分重用已被釋放的物件使得下次分配時無需初始化，那麼可以提高核心的執行效率。
分配器對核心物件緩衝區的組織和管理必須充分考慮對硬體快取記憶體的影響。
隨著共享記憶體的多處理器系統的普及，多處理器同時分配某種型別物件的現象時常發生，因此分配器應該盡量避免處理器間同步的開銷，應採用某種 lock-free 的演算法。
如何有效地管理緩衝區空間，長期以來都是乙個熱門的研究課題。90 年代初期，在 solaris 2.4 作業系統中，採用了一種稱為「slab」（原意是大塊的混凝土）的緩衝區分配和管理方法，在相當程度上滿足了核心的特殊需求。
回頁首
slub 分配器的設計原理
slab 分配器多年以來一直位於 linux 核心的記憶體管理部分的核心地帶，核心黑客們一般不願意主動去更改它的**，因為它實在是非常複雜，而且在大多數情況下，它的工作完成的相當不錯。但是，隨著大規模多處理器系統和 numa系統的廣泛應用，slab 分配器逐漸暴露出自身的嚴重不足：
本文**ibm developerworks中國
Linux Slub分配器 一 概述
slab分配器一直處於核心記憶體管理的核心地位，儘管如此，它還是擁有自身的缺點，最明顯的兩點就是複雜性和過多的管理資料造成的記憶體上的開銷。針對這些問題，linux引入了slub分配器，slub分配器保留了slab分配器的所有介面，實際上slub分配器的模型和slab分配的模型是基本一致的，只不過在...
Linux Slub分配器 五 釋放物件
釋放物件和分配物件是一組對稱的操作，同樣分為兩個路徑 1.如果待釋放的物件所屬的slab位於本地cpu快取中，也就是slab處於凍結狀態，則可直接釋放 2.反之，待釋放的物件所屬的slab位於slab鍊錶中，也就是slab處於解凍狀態，則要通過慢速路徑進行釋放。函式kmem cache free 用...
Linux slab 分配器詳解
投稿收藏 良好的作業系統效能部分依賴於操作 系統有效管理資源的能力。在過去，堆記憶體管理器是實際的規範，但是其效能會受到記憶體碎片和記憶體 需求的影響。現在，linux？核心使用了源自於 solaris 的一種方法，但是這種方法在嵌入式系統中已經使用了很長時間了，它是將記憶體作為物件按照大小進行分配...