在系統初始化進行到夥伴系統分配器能夠承擔記憶體管理的責任後，必須停用bootmem分配器，畢竟不能同時用兩個分配器管理記憶體。在uma和numa系統上，停用分別由free_all_bootmem和free_all_bootmem_node完成（前面的部落格已經詳細討論過）。夥伴系統基於一種相對簡單而令人吃驚的強大演算法，它結合了優秀記憶體分配器的兩個關鍵特性：速度和效率。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個頁框的鍊錶查詢，如果仍然沒有，則返回錯誤。
頁框塊在釋放時，會主動將兩個連續的頁框塊合併為乙個較大的頁框塊。
為清楚了解其分配制度，先給個夥伴系統資料的儲存框圖如下：
也就是每個order對應乙個free_area結構，free_area以不同的型別以鍊錶的方式儲存這些記憶體塊。
主要的資料域結構分析：
struct zone
;
struct free_area ;#define migrate_unmovable 0 //不可移動頁：在記憶體中有固定位置，不能移動到其他地方
#define migrate_reclaimable 1 //可**頁：不能直接移動，但可以刪除，其內容可以從某些源重新生成
#define migrate_movable 2 //可移動頁：可以隨意的移動
#define migrate_reserve 3 //如果向具有特定可移動性地列表請求分配記憶體失敗，這種緊急情況下可以從migrate_reserve分配記憶體
#define migrate_isolate 4 //是乙個特殊的虛擬區域，用於跨域numa結點移動物理記憶體頁，在大型系統上，它有益於將物理記憶體頁移動到接近於是用該頁最頻繁的cpu
#define migrate_types 5 //只是表示遷移型別的數目，不代表具體的區域
linux記憶體管理 夥伴系統演算法
分配記憶體 釋放記憶體 兩個塊的大小相同 兩個塊的位址連續 兩個塊必須是從同乙個大塊分離出來的 linux把每個zone分成max order個free area，每個free are的大小是2的冪次方。max order的值為11，第0組大小為2 0個頁，第1組大小為2 1個頁，依次類推，最大的是...
記憶體管理之夥伴演算法
通常情況下，乙個高階作業系統必須要給程序提供基本的 能夠在任意時刻申請和釋放任意大小記憶體的功能，就像malloc 函式那樣，然而，實現malloc 函式並不簡單，由於程序申請記憶體的大小是任意的，如果作業系統對malloc 函式的實現方法不對，將直接導致乙個不可避免的問題，那就是記憶體碎片。記憶體...
記憶體管理演算法 Buddy夥伴演算法
buddy演算法的優缺點 1 儘管夥伴記憶體演算法在記憶體碎片問題上已經做的相當出色，但是該演算法中，乙個很小的塊往往會阻礙乙個大塊的合併，乙個系統中，對記憶體塊的分配，大小是隨機的，一片記憶體中僅乙個小的記憶體塊沒有釋放，旁邊兩個大的就不能合併。2 演算法中有一定的浪費現象，夥伴演算法是按2的冪次...