夥伴系統
linux核心中採用了一種同時適用於32位和64位系統的記憶體分頁模型，對於32位系統來說，兩級頁表足夠用了，而在x86_64系統中，用到了四級頁表。四級頁表分別為：
頁全域性目錄(page global directory)
頁上級目錄(page upper directory)
頁中間目錄(page middle directory)
頁表(page table)
頁全域性目錄包含若干頁上級目錄的位址，頁上級目錄又依次包含若干頁中間目錄的位址，而頁中間目錄又包含若干頁表的位址，每乙個頁表項指向乙個頁框。linux中採用4kb大小的頁框作為標準的記憶體分配單元。
在實際應用中，經常需要分配一組連續的頁框，而頻繁地申請和釋放不同大小的連續頁框，必然導致在已分配頁框的記憶體塊中分散了許多小塊的空閒頁框。這樣，即使這些頁框是空閒的，其他需要分配連續頁框的應用也很難得到滿足。
為了避免出現這種情況，linux核心中引入了夥伴系統演算法(buddy system)。把所有的空閒頁框分組為11個塊鍊錶，每個塊鍊錶分別包含大小為1，2，4，8，16，32，64，128，256，512和1024個連續頁框的頁框塊。最大可以申請1024個連續頁框，對應4mb大小的連續記憶體。每個頁框塊的第乙個頁框的實體地址是該塊大小的整數倍。
假設要申請乙個256個頁框的塊，先從256個頁框的鍊錶中查詢空閒塊，如果沒有，就去512個頁框的鍊錶中找，找到了則將頁框塊分為2個256個頁框的塊，乙個分配給應用，另外乙個移到256個頁框的鍊錶中。如果512個頁框的鍊錶中仍沒有空閒塊，繼續向1024個頁框的鍊錶查詢，如果仍然沒有，則返回錯誤。
頁框塊在釋放時，會主動將兩個連續的頁框塊合併為乙個較大的頁框塊。
buddy演算法的優缺點：
1）儘管夥伴記憶體演算法在記憶體碎片問題上已經做的相當出色，但是該演算法中，乙個很小的塊往往會阻礙乙個大塊的合併，乙個系統中，對記憶體塊的分配，大小是隨機的，一片記憶體中僅乙個小的記憶體塊沒有釋放，旁邊兩個大的就不能合併。
2）演算法中有一定的浪費現象，夥伴演算法是按2的冪次方大小進行分配記憶體塊，當然這樣做是有原因的，即為了避免把大的記憶體塊拆的太碎，更重要的是使分配和釋放過程迅速。但是他也帶來了不利的一面，如果所需記憶體大小不是2的冪次方，就會有部分頁面浪費。有時還很嚴重。比如原來是1024個塊，申請了16個塊，再申請600個塊就申請不到了，因為已經被分割了。
3）另外拆分和合併涉及到 較多的鍊錶和位圖操作，開銷還是比較大的。
buddy（夥伴的定義）：
buddy演算法的分配原理：
假如系統需要4(2*2)個頁面大小的記憶體塊，該演算法就到free_area[2]中查詢，如果鍊錶中有空閒塊，就直接從中摘下並分配出去。如果沒有，演算法將順著陣列向上查詢free_area[3],如果free_area[3]中有空閒塊，則將其從鍊錶中摘下，分成等大小的兩部分，前四個頁面作為乙個塊插入free_area[2]，後4個頁面分配出去，free_area[3]中也沒有，就再向上查詢，如果free_area[4]中有，就將這16(2*2*2*2)個頁面等分成兩份，前一半掛如free_area[3]的鍊錶頭部，後一半的8個頁等分成兩等分，前一半掛free_area[2]
的鍊錶中，後一半分配出去。假如free_area[4]也沒有，則重複上面的過程，知道到達free_area陣列的最後，如果還沒有則放棄分配。
buddy演算法的釋放原理：
記憶體的釋放是分配的逆過程，也可以看作是夥伴的合併過程。當釋放乙個塊時，先在其對應的鍊錶中考查是否有夥伴存在，如果沒有夥伴塊，就直接把要釋放的塊掛入煉表頭；如果有，則從鍊錶中摘下夥伴，合併成乙個大塊，然後繼續考察合併後的塊在更大一級鍊錶中是否有夥伴存在，直到不能合併或者已經合併到了最大的塊(2*2*2*2*2*2*2*2*2個頁面)。
slab機制
slab是linux作業系統的一種記憶體分配機制。其工作是針對一些經常分配並釋放的物件，如程序描述符等，這些物件的大小一般比較小，如果直接採用夥伴系統來進行分配和釋放，不僅會造成大量的內碎片，而且處理速度也太慢。而slab分配器是基於物件進行管理的，相同型別的物件歸為一類(如程序描述符就是一類)，每當要申請這樣乙個物件，slab分配器就從乙個slab列表中分配乙個這樣大小的單元出去，而當要釋放時，將其重新儲存在該列表中，而不是直接返回給夥伴系統，從而避免這些內碎片。slab分配器並不丟棄已分配的物件，而是釋放並把它們儲存在記憶體中。當以後又要請求新的物件時，就可以從記憶體直接獲取而不用重複初始化。
linux 的slab 可有三種狀態：
滿的：slab 中的所有物件被標記為使用。
空的：slab 中的所有物件被標記為空閒。
部分：slab 中的物件有的被標記為使用，有的被標記為空閒。
slab 分配器首先從部分空閒的slab 進行分配。如沒有，則從空的slab 進行分配。如沒有，則從物理連續頁上分配新的slab，並把它賦給乙個cache ，然後再從新slab 分配空間。
與傳統的記憶體管理模式相比， slab 快取分配器提供了很多優點。
1、核心通常依賴於對小物件的分配，它們會在系統生命週期內進行無數次分配。
2、slab 快取分配器通過對類似大小的物件進行快取而提供這種功能，從而避免了常見的碎片問題。
3、slab 分配器還支援通用物件的初始化，從而避免了為同一目的而對乙個物件重複進行初始化。
4、slab 分配器還可以支援硬體快取對齊和著色，這允許不同快取中的物件占用相同的快取行，從而提高快取的利用率並獲得更好的效能。
Linux頁框 夥伴演算法以及slab機制
無論是上層應用還是作業系統核心開發，記憶體問題都是我們所需要關注的。我們來看看linux核心管理和分配機制。夥伴演算法 夥伴演算法從物理連續的大小固定的段上進行分配。從這個段上分配記憶體，採用 2 的冪分配器來滿足請求分配單元的大小為 2 的冪 4kb 8kb 16kb 等 請求單元的大小如不適當，...
linux記憶體管理的 夥伴系統和slab機制
夥伴系統 linux核心中採用了一種同時適用於32位和64位系統的記憶體分頁模型，對於32位系統來說，兩級頁表足夠用了，而在x86 64系統中，用到了四級頁表。四級頁表分別為 頁全域性目錄 page global directory 頁上級目錄 page upper directory 頁中間目錄 ...
slab機制解析
2 原始碼解讀 slab是linux在夥伴系統之上的一種記憶體管理機制。夥伴系統最小的記憶體處理大小為4k 即一頁的記憶體大小 然而，實際使用記憶體過程中，很多都是小記憶體，為了提高記憶體申請釋放效率 防止記憶體碎片的產生 防止記憶體連續分配導致cpu快取命中率低，linux在夥伴系統之上設計出sl...