夥伴系統之夥伴系統概述--Linux記憶體管理(十五)
在核心初始化完成之後, 記憶體管理的責任就由夥伴系統來承擔. 夥伴系統基於一種相對簡單然而令人吃驚的強大演算法.
Linux核心使用二進位制夥伴演算法來管理和分配實體記憶體頁面, 該演算法由Knowlton設計, 後來Knuth又進行了更深刻的描述.
夥伴系統是一個結合了2的方冪個分配器和空閒緩衝區合併計技術的記憶體分配方案, 其基本思想很簡單. 記憶體被分成含有很多頁面的大塊, 每一塊都是2個頁面大小的方冪. 如果找不到想要的塊, 一個大塊會被分成兩部分, 這兩部分彼此就成為夥伴. 其中一半被用來分配, 而另一半則空閒. 這些塊在以後分配的過程中會繼續被二分直至產生一個所需大小的塊. 當一個塊被最終釋放時, 其夥伴將被檢測出來, 如果夥伴也空閒則合併兩者.
- 核心如何記住哪些記憶體塊是空閒的
- 分配空閒頁面的方法
- 影響分配器行為的眾多標識位
- 記憶體碎片的問題和分配器如何處理碎片
2 夥伴系統的結構
2.1 夥伴系統資料結構
系統記憶體中的每個實體記憶體頁（頁幀），都對應於一個struct page例項, 每個記憶體域都關聯了一個struct zone的例項，其中儲存了用於管理夥伴資料的主要數陣列
// http://lxr.free-electrons.com/source/include/linux/mmzone.h?v=4.7#L324 struct zone { /* free areas of different sizes */ struct free_area free_area[MAX_ORDER]; };
struct free_area是一個夥伴系統的輔助資料結構, 它定義在include/linux/mmzone.h?v=4.7, line 88
struct free_area {
struct list_head free_list[MIGRATE_TYPES];
unsigned long nr_free;
};| 欄位 | 描述 |
|---|---|
| free_list | 是用於連線空閒頁的連結串列. 頁連結串列包含大小相同的連續記憶體區 |
| nr_free | 指定了當前記憶體區中空閒頁塊的數目（對0階記憶體區逐頁計算，對1階記憶體區計算頁對的數目，對2階記憶體區計算4頁集合的數目，依次類推 |
夥伴系統的分配器維護空閒頁面所組成的塊, 這裡每一塊都是2的方冪個頁面, 方冪的指數稱為階.
階是夥伴系統中一個非常重要的術語. 它描述了記憶體分配的數量單位. 記憶體塊的長度是2^0,order , 其中order的範圍從0到MAX_ORDER
zone->free_area[MAX_ORDER]陣列中階作為各個元素的索引, 用於指定對應連結串列中的連續記憶體區包含多少個頁幀.
- 陣列中第0個元素的階為0, 它的free_list連結串列域指向具有包含區為單頁(2^0 = 1)的記憶體頁面連結串列
- 陣列中第1個元素的free_list域管理的記憶體區為兩頁(2^1 = 2)
- 第3個管理的記憶體區為4頁, 依次類推.
- 直到 2^MAXORDER-1個頁面大小的塊
2.2 最大階MAX_ORDER與FORCE_MAX_ZONEORDER配置選項
一般來說MAX_ORDER預設定義為11, 這意味著一次分配可以請求的頁數最大是2^11=2048, 參見include/linux/mmzone.h?v=4.7, line 22
/* Free memory management - zoned buddy allocator. */
#ifndef CONFIG_FORCE_MAX_ZONEORDER
#define MAX_ORDER 11
#else
#define MAX_ORDER CONFIG_FORCE_MAX_ZONEORDER
#endif
#define MAX_ORDER_NR_PAGES (1 << (MAX_ORDER - 1))但如果特定於體系結構的程式碼設定了FORCE_MAX_ZONEORDER配置選項, 該值也可以手工改變
例如，IA-64系統上巨大的地址空間可以處理MAX_ORDER = 18的情形，而ARM或v850系統則使用更小的值(如8或9). 但這不一定是由計算機支援的記憶體數量比較小引起的，也可能是記憶體對齊方式的要求所導致
可以參考一些架構的Kconfig檔案如下
| arm | arm64 |
|---|---|
| arch/arm/Kconfig?v=4.7, line 1696 | arch/arm64/Kconfig?v=4.7, line 679 |
config FORCE_MAX_ZONEORDER
int
default "14" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
default "12" if (ARM64_16K_PAGES && TRANSPARENT_HUGEPAGE)
default "11"2.3 記憶體區是如何連線的
記憶體區中第1頁內的連結串列元素, 可用於將記憶體區維持在連結串列中。因此，也不必引入新的資料結構來管理物理上連續的頁，否則這些頁不可能在同一記憶體區中. 如下圖所示
夥伴不必是彼此連線的. 如果一個記憶體區在分配其間分解為兩半, 核心會自動將未用的一半加入到對應的連結串列中.
如果在未來的某個時刻, 由於記憶體釋放的緣故, 兩個記憶體區都處於空閒狀態, 可通過其地址判斷其是否為夥伴. 管理工作較少, 是夥伴系統的一個主要優點.
基於夥伴系統的記憶體管理專注於某個結點的某個記憶體域, 例如, DMA或高階記憶體域. 但所有記憶體域和結點的夥伴系統都通過備用分配列表連線起來.
下圖說明了這種關係.
最後要注意, 有關夥伴系統和當前狀態的資訊可以在/proc/buddyinfo中獲取
核心中很多時候要求分配連續頁. 為快速檢測記憶體中的連續區域, 核心採用了一種古老而歷經檢驗的技術: 夥伴系統
系統中的空閒記憶體塊總是兩兩分組, 每組中的兩個記憶體塊稱作夥伴. 夥伴的分配可以是彼此獨立的. 但如果兩個夥伴都是空閒的, 核心會將其合併為一個更大的記憶體塊, 作為下一層次上某個記憶體塊的夥伴.
下圖示範了該系統, 圖中給出了一對夥伴, 初始大小均為8頁. 即系統中所有的頁面都是8頁的.
核心對所有大小相同的夥伴（1、2、4、8、16或其他數目的頁），都放置到同一個列表中管理. 各有8頁的一對夥伴也在相應的列表中.
如果系統現在需要8個頁幀, 則將16個頁幀組成的塊拆分為兩個夥伴. 其中一塊用於滿足應用程式的請求, 而剩餘的8個頁幀則放置到對應8頁大小記憶體塊的列表中.
如果下一個請求只需要2個連續頁幀, 則由8頁組成的塊會分裂成2個夥伴, 每個包含4個頁幀. 其中一塊放置回夥伴列表中，而另一個再次分裂成2個夥伴, 每個包含2頁。其中一個回到夥伴系統，另一個則傳遞給應用程式.
在應用程式釋放記憶體時, 核心可以直接檢查地址, 來判斷是否能夠建立一組夥伴, 併合併為一個更大的記憶體塊放回到夥伴列表中, 這剛好是記憶體塊分裂的逆過程。這提高了較大記憶體塊可用的可能性.
在系統長期執行時，伺服器執行幾個星期乃至幾個月是很正常的，許多桌面系統也趨向於長期開機執行，那麼會發生稱為碎片的記憶體管理問題。頻繁的分配和釋放頁幀可能導致一種情況：系統中有若干頁幀是空閒的，但卻散佈在實體地址空間的各處。換句話說，系統中缺乏連續頁幀組成的較大的記憶體塊，而從效能上考慮，卻又很需要使用較大的連續記憶體塊。通過夥伴系統可以在某種程度上減少這種效應，但無法完全消除。如果在大塊的連續記憶體中間剛好有一個頁幀分配出去，很顯然這兩塊空閒的記憶體是無法合併的.
在核心版本2.6.24之後, 增加了一些有效措施來防止記憶體碎片.
3 避免碎片
在第1章給出的簡化說明中, 一個雙鏈表即可滿足夥伴系統的所有需求. 在核心版本2.6.23之前, 的確是這樣. 但在核心2.6.24開發期間, 核心開發者對夥伴系統的爭論持續了相當長時間. 這是因為夥伴系統是核心最值得尊敬的一部分，對它的改動不會被大家輕易接受
3.1 記憶體碎片
夥伴系統的基本原理已經在第1章中討論過，其方案在最近幾年間確實工作得非常好。但在Linux記憶體管理方面，有一個長期存在的問題：在系統啟動並長期執行後，實體記憶體會產生很多碎片。該情形如下圖所示
假定記憶體由60頁組成，這顯然不是超級計算機，但用於示例卻足夠了。左側的地址空間中散佈著空閒頁。儘管大約25%的實體記憶體仍然未分配，但最大的連續空閒區只有一頁. 這對使用者空間應用程式沒有問題：其記憶體是通過頁表對映的，無論空閒頁在實體記憶體中的分佈如何，應用程式看到的記憶體 似乎總是連續的。右圖給出的情形中，空閒頁和使用頁的數目與左圖相同，但所有空閒頁都位於一個連續區中。
但對核心來說，碎片是一個問題. 由於(大多數)實體記憶體一致對映到地址空間的核心部分, 那麼在左圖的場景中, 無法對映比一頁更大的記憶體區. 儘管許多時候核心都分配的是比較小的記憶體, 但也有時候需要分配多於一頁的記憶體. 顯而易見, 在分配較大記憶體的情況下, 右圖中所有已分配頁和空閒頁都處於連續記憶體區的情形，是更為可取的.
很有趣的一點是, 在大部分記憶體仍然未分配時, 就也可能發生碎片問題. 考慮圖3-25的情形.
只分配了4頁，但可分配的最大連續區只有8頁，因為夥伴系統所能工作的分配範圍只能是2的冪次.
我提到記憶體碎片只涉及核心，這只是部分正確的。大多數現代CPU都提供了使用巨型頁的可能性，比普通頁大得多。這對記憶體使用密集的應用程式有好處。在使用更大的頁時，地址轉換後備緩衝器只需處理較少的項，降低了TLB快取失效的可能性。但分配巨型頁需要連續的空閒實體記憶體！
很長時間以來，實體記憶體的碎片確實是Linux的弱點之一。儘管已經提出了許多方法，但沒有哪個方法能夠既滿足Linux需要處理的各種型別工作負荷提出的苛刻需求，同時又對其他事務影響不大。
3.2 依據可移動性組織頁
在核心2.6.24開發期間，防止碎片的方法最終加入核心。在我討論具體策略之前，有一點需要澄清。
檔案系統也有碎片，該領域的碎片問題主要通過碎片合併工具解決。它們分析檔案系統，重新排序已分配儲存塊，從而建立較大的連續儲存區. 理論上，該方法對實體記憶體也是可能的，但由於許多實體記憶體頁不能移動到任意位置，阻礙了該方法的實施。因此，核心的方法是反碎片(anti-fragmentation), 即試圖從最初開始儘可能防止碎片.
反碎片的工作原理如何?
為理解該方法，我們必須知道核心將已分配頁劃分為下面3種不同型別。
| 頁面型別 | 描述 | 舉例 |
|---|---|---|
| 不可移動頁 | 在記憶體中有固定位置, 不能移動到其他地方. | 核心核心分配的大多數記憶體屬於該類別 |
| 可移動頁 | 可以隨意地移動. 屬於使用者空間應用程式的頁屬於該類別. | 它們是通過頁表對映的 如果它們複製到新位置，頁表項可以相應地更新，應用程式不會注意到任何事 |
| 可回收頁 | 不能直接移動, 但可以刪除, 其內容可以從某些源重新生成. | 例如，對映自檔案的資料屬於該類別 kswapd守護程序會根據可回收頁訪問的頻繁程度，週期性釋放此類記憶體. , 頁面回收本身就是一個複雜的過程. 核心會在可回收頁佔據了太多記憶體時進行回收, 在記憶體短缺(即分配失敗)時也可以發起頁面回收. |
頁的可移動性，依賴該頁屬於3種類別的哪一種. 核心使用的反碎片技術, 即基於將具有相同可移動性的頁分組的思想.
為什麼這種方法有助於減少碎片?
由於頁無法移動, 導致在原本幾乎全空的記憶體區中無法進行連續分配. 根據頁的可移動性, 將其分配到不同的列表中, 即可防止這種情形. 例如, 不可移動的頁不能位於可移動記憶體區的中間, 否則就無法從該記憶體區分配較大的連續記憶體塊.
想一下, 上圖中大多數空閒頁都屬於可回收的類別, 而分配的頁則是不可移動的. 如果這些頁聚集到兩個不同的列表中, 如下圖所示. 在不可移動頁中仍然難以找到較大的連續空閒空間, 但對可回收的頁, 就容易多了.
但要注意, 從最初開始, 記憶體並未劃分為可移動性不同的區. 這些是在執行時形成的. 核心的另一種方法確實將記憶體分割槽, 分別用於可移動頁和不可移動頁的分配, 我會下文討論其工作原理. 但這種劃分對這裡描述的方法是不必要的
3.3 避免碎片資料結構
3.3.1 遷移型別
儘管核心使用的反碎片技術卓有成效，它對夥伴分配器的程式碼和資料結構幾乎沒有影響。核心定義了一些列舉常量(早期用巨集來實現)來表示不同的遷移型別, 參見include/linux/mmzone.h?v=4.7, line 38
enum {
MIGRATE_UNMOVABLE,
MIGRATE_MOVABLE,
MIGRATE_RECLAIMABLE,
MIGRATE_PCPTYPES, /* the number of types on the pcp lists */
MIGRATE_HIGHATOMIC = MIGRATE_PCPTYPES,
#ifdef CONFIG_CMA
/*
* MIGRATE_CMA migration type is designed to mimic the way
* ZONE_MOVABLE works. Only movable pages can be allocated
* from MIGRATE_CMA pageblocks and page allocator never
* implicitly change migration type of MIGRATE_CMA pageblock.
*
* The way to use it is to change migratetype of a range of
* pageblocks to MIGRATE_CMA which can be done by
* __free_pageblock_cma() function. What is important though
* is that a range of pageblocks must be aligned to
* MAX_ORDER_NR_PAGES should biggest page be bigger then
* a single pageblock.
*/
MIGRATE_CMA,
#endif
#ifdef CONFIG_MEMORY_ISOLATION
MIGRATE_ISOLATE, /* can't allocate from here */
#endif
MIGRATE_TYPES
};| 巨集 | 型別 |
|---|---|
| MIGRATE_UNMOVABLE | 不可移動頁 |
| MIGRATE_MOVABLE | 可移動頁 |
| MIGRATE_RECLAIMABLE | 可回收頁 |
| MIGRATE_PCPTYPES | 是per_cpu_pageset, 即用來表示每CPU頁框快取記憶體的資料結構中的連結串列的遷移型別數目 |
| MIGRATE_HIGHATOMIC | 在罕見的情況下，核心需要分配一個高階的頁面塊而不能休眠.如果向具有特定可移動性的列表請求分配記憶體失敗，這種緊急情況下可從MIGRATE_HIGHATOMIC中分配記憶體 |
| MIGRATE_CMA | Linux核心最新的連續記憶體分配器(CMA), 用於避免預留大塊記憶體 |
| MIGRATE_ISOLATE | 是一個特殊的虛擬區域, 用於跨越NUMA結點移動實體記憶體頁. 在大型系統上, 它有益於將實體記憶體頁移動到接近於使用該頁最頻繁的CPU. |
| MIGRATE_TYPES | 只是表示遷移型別的數目, 也不代表具體的區域 |
對於MIGRATE_CMA型別, 其中在我們使用ARM等嵌入式Linux系統的時候, 一個頭疼的問題是GPU, Camera, HDMI等都需要預留大量連續記憶體，這部分記憶體平時不用，但是一般的做法又必須先預留著. 目前, Marek Szyprowski和Michal Nazarewicz實現了一套全新的Contiguous Memory Allocator. 通過這套機制, 我們可以做到不預留記憶體，這些記憶體平時是可用的，只有當需要的時候才被分配給Camera，HDMI等裝置. 參照宋寶華–Linux核心最新的連續記憶體分配器(CMA)——避免預留大塊記憶體, 核心為此提供了函式is_migrate_cma來檢測當前型別是否為MIGRATE_CMA, 該函式定義在include/linux/mmzone.h?v=4.7, line 69
/* In mm/page_alloc.c; keep in sync also with show_migration_types() there */
extern char * const migratetype_names[MIGRATE_TYPES];
#ifdef CONFIG_CMA
# define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
#else
# define is_migrate_cma(migratetype) false
#endif對夥伴系統資料結構的主要調整, 是將空閒列表分解為MIGRATE_TYPE個列表, 可以參見free_area的定義include/linux/mmzone.h?v=4.7, line 88
struct free_area
{
struct list_head free_list[MIGRATE_TYPES];
unsigned long nr_free;
};- nr_free統計了所有列表上空閒頁的數目，而每種遷移型別都對應於一個空閒列表
巨集for_each_migratetype_order(order, type)可用於迭代指定遷移型別的所有分配階
#define for_each_migratetype_order(order, type) \
for (order = 0; order < MAX_ORDER; order++) \
for (type = 0; type < MIGRATE_TYPES; type++)3.3.2 遷移備用列表fallbacks
如果核心無法滿足針對某一給定遷移型別的分配請求, 會怎麼樣?
此前已經出現過一個類似的問題, 即特定的NUMA記憶體域無法滿足分配請求時. 我們需要從其他記憶體域中選擇一個代價最低的記憶體域完成記憶體的分配, 因此核心在記憶體的結點pg_data_t中提供了一個備用記憶體域列表zonelists.
核心在記憶體遷移的過程中處理這種情況下的做法是類似的. 提供了一個備用列表fallbacks, 規定了在指定列表中無法滿足分配請求時. 接下來應使用哪一種遷移型別, 定義在mm/page_alloc.c?v=4.7, line 1799
/*
* This array describes the order lists are fallen back to when
* the free lists for the desirable migrate type are depleted
* 該陣列描述了指定遷移型別的空閒列表耗盡時
* 其他空閒列表在備用列表中的次序
*/
static int fallbacks[MIGRATE_TYPES][4] = {
// 分配不可移動頁失敗的備用列表
[MIGRATE_UNMOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE, MIGRATE_TYPES },
// 分配可回收頁失敗時的備用列表
[MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE, MIGRATE_MOVABLE, MIGRATE_TYPES },
// 分配可移動頁失敗時的備用列表
[MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE, MIGRATE_TYPES },
#ifdef CONFIG_CMA
[MIGRATE_CMA] = { MIGRATE_TYPES }, /* Never used */
#endif
#ifdef CONFIG_MEMORY_ISOLATION
[MIGRATE_ISOLATE] = { MIGRATE_TYPES }, /* Never used */
#endif
};該資料結構大體上是自明的 :
每一行對應一個型別的備用搜索域的順序, 在核心想要分配不可移動頁MIGRATE_UNMOVABLE時, 如果對應連結串列為空, 則遍歷fallbacks[MIGRATE_UNMOVABLE], 首先後退到可回收頁連結串列MIGRATE_RECLAIMABLE, 接下來到可移動頁連結串列MIGRATE_MOVABLE, 最後到緊急分配連結串列MIGRATE_TYPES.
3.3.3 pageblock_order變數
全域性變數和輔助函式儘管頁可移動性分組特性總是編譯到核心中，但只有在系統中有足夠記憶體可以分配到多個遷移型別對應的連結串列時，才是有意義的。由於每個遷移連結串列都應該有適當數量的記憶體，核心需要定義”適當”的概念. 這是通過兩個全域性變數pageblock_order和pageblock_nr_pages提供的. 第一個表示核心認為是”大”的一個分配階, pageblock_nr_pages則表示該分配階對應的頁數。如果體系結構提供了巨型頁機制, 則pageblock_order通常定義為巨型頁對應的分配階. 定義在include/linux/pageblock-flags.h?v=4.7, line 44
#ifdef CONFIG_HUGETLB_PAGE
#ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
/* Huge page sizes are variable */
extern unsigned int pageblock_order;
#else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
/* Huge pages are a constant size */
#define pageblock_order HUGETLB_PAGE_ORDER
#endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
#else /* CONFIG_HUGETLB_PAGE */
/* If huge pages are not used, group by MAX_ORDER_NR_PAGES */
#define pageblock_order (MAX_ORDER-1)
#endif /* CONFIG_HUGETLB_PAGE */
#define pageblock_nr_pages (1UL << pageblock_order)在IA-32體系結構上, 巨型頁長度是4MB, 因此每個巨型頁由1024個普通頁組成, 而HUGETLB_PAGE_ORDER則定義為10. 相比之下, IA-64體系結構允許設定可變的普通和巨型頁長度, 因此HUGETLB_PAGE_ORDER的值取決於核心配置.
如果體系結構不支援巨型頁, 則將其定義為第二高的分配階, 即MAX_ORDER - 1
/* If huge pages are not used, group by MAX_ORDER_NR_PAGES */
#define pageblock_order (MAX_ORDER-1)
如果各遷移型別的連結串列中沒有一塊較大的連續記憶體, 那麼頁面遷移不會提供任何好處, 因此在可用記憶體太少時核心會關閉該特性. 這是在build_all_zonelists函式中檢查的, 該函式用於初始化記憶體域列表. 如果沒有足夠的記憶體可用, 則全域性變數page_group_by_mobility_disabled設定為0, 否則設定為1.
核心如何知道給定的分配記憶體屬於何種遷移型別?
我們將在以後講解, 有關各個記憶體分配的細節都通過分配掩碼指定.
核心提供了兩個標誌，分別用於表示分配的記憶體是可移動的(__GFP_MOVABLE)或可回收的(__GFP_RECLAIMABLE).
3.3.4 gfpflags_to_migratetype函式
/* Convert GFP flags to their corresponding migrate type */
static inline int allocflags_to_migratetype(gfp_t gfp_flags)
{
WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
if (unlikely(page_group_by_mobility_disabled))
return MIGRATE_UNMOVABLE;
/* Group based on mobility */
return (((gfp_flags & __GFP_MOVABLE) != 0) << 1) |
((gfp_flags & __GFP_RECLAIMABLE) != 0);
}如果停用了頁面遷移特性, 則所有的頁都是不可移動的. 否則. 該函式的返回值可以直接用作free_area.free_list的陣列索引.
3.3.5 pageblock_flags變數與其函式介面
最後要注意, 每個記憶體域都提供了一個特殊的欄位, 可以跟蹤包含pageblock_nr_pages個頁的記憶體區的屬性. 即zone->pageblock_flags欄位, 當前只有與頁可移動性相關的程式碼使用, 參見include/linux/mmzone.h?v=4.7, line 367
struct zone
{
#ifndef CONFIG_SPARSEMEM
/*
* Flags for a pageblock_nr_pages block. See pageblock-flags.h.
* In SPARSEMEM, this map is stored in struct mem_section
*/
unsigned long *pageblock_flags;
#endif /* CONFIG_SPARSEMEM */
};在初始化期間, 核心自動確保對記憶體域中的每個不同的遷移型別分組, 在pageblock_flags中都分配了足夠儲存NR_PAGEBLOCK_BITS個位元位的空間。當前，表示一個連續記憶體區的遷移型別需要3個位元位, 參見include/linux/pageblock-flags.h?v=4.7, line 28
/* Bit indices that affect a whole block of pages */
enum pageblock_bits {
PB_migrate,
PB_migrate_end = PB_migrate + 3 - 1,
/* 3 bits required for migrate types */
PB_migrate_skip,/* If set the block is skipped by compaction */
/*
* Assume the bits will always align on a word. If this assumption
* changes then get/set pageblock needs updating.
*/
NR_PAGEBLOCK_BITS
};核心提供set_pageblock_migratetype負責設定以page為首的一個記憶體區的遷移型別, 該函式定義在mm/page_alloc.c?v=4.7, line 458, 如下所示
void set_pageblock_migratetype(struct page *page, int migratetype)
{
if (unlikely(page_group_by_mobility_disabled &&
migratetype < MIGRATE_PCPTYPES))
migratetype = MIGRATE_UNMOVABLE;
set_pageblock_flags_group(page, (unsigned long)migratetype,
PB_migrate, PB_migrate_end);
}migratetype引數可以通過上文介紹的gfpflags_to_migratetype輔助函式構建. 請注意很重要的一點, 頁的遷移型別是預先分配好的, 對應的位元位總是可用, 與頁是否由夥伴系統管理無關. 在釋放記憶體時，頁必須返回到正確的遷移連結串列。這之所以可行，是因為能夠從get_pageblock_migratetype獲得所需的資訊. 參見include/linux/mmzone.h?v=4.7, line 84
#define get_pageblock_migratetype(page) \
get_pfnblock_flags_mask(page, page_to_pfn(page), \
PB_migrate_end, MIGRATETYPE_MASK)最後請注意, 在各個遷移連結串列之間, 當前的頁面分配狀態可以從/proc/pagetypeinfo獲得.
初始化基於可移動性的分組
在記憶體子系統初始化期間, memmap_init_zone負責處理記憶體域的page例項. 該函式定義在mm/page_alloc.c?v=4.7, line 5139, 該函式完成了一些不怎麼有趣的標準初始化工作，但其中有一件是實質性的，即所有的頁最初都標記為可移動的. 參見mm/page_alloc.c?v=4.7, line 5224
/*
* Initially all pages are reserved - free ones are freed
* up by free_all_bootmem() once the early boot process is
* done. Non-atomic initialization, single-pass.
*/
void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
unsigned long start_pfn, enum memmap_context context)
{
/* ...... */
for (pfn = start_pfn; pfn < end_pfn; pfn++) {
/* ...... */
not_early:
if (!(pfn & (pageblock_nr_pages - 1))) {
struct page *page = pfn_to_page(pfn);
__init_single_page(page, pfn, zone, nid);
set_pageblock_migratetype(page, MIGRATE_MOVABLE);
} else {
__init_single_pfn(pfn, zone, nid);
}
}
}在分配記憶體時, 如果必須”盜取”不同於預定遷移型別的記憶體區, 核心在策略上傾向於”盜取”更大的記憶體區. 由於所有頁最初都是可移動的, 那麼在核心分配不可移動的記憶體區時, 則必須”盜取”.
實際上, 在啟動期間分配可移動記憶體區的情況較少, 那麼分配器有很高的機率分配長度最大的記憶體區, 並將其從可移動列表轉換到不可移動列表. 由於分配的記憶體區長度是最大的, 因此不會向可移動記憶體中引入碎片.
總而言之, 這種做法避免了啟動期間核心分配的記憶體(經常在系統的整個執行時間都不釋放)散佈到實體記憶體各處, 從而使其他型別的記憶體分配免受碎片的干擾，這也是頁可移動性分組框架的最重要的目標之一.
4 分配器API
4.1 分配記憶體的介面
就夥伴系統的介面而言, NUMA或UMA體系結構是沒有差別的, 二者的呼叫語法都是相同的.
所有函式的一個共同點是 : 只能分配2的整數冪個頁.
因此，介面中不像C標準庫的malloc函式或bootmem和memblock分配器那樣指定了所需記憶體大小作為引數. 相反, 必須指定的是分配階, 夥伴系統將在記憶體中分配2^0 rder頁. 核心中細粒度的分配只能藉助於slab分配器(或者slub、slob分配器), 後者基於夥伴系統
| 記憶體分配函式 | 功能 | 定義 |
|---|---|---|
| alloc_pages(mask, order) | 分配2^0頁並返回一個struct page的例項，表示分配的記憶體塊的起始頁 | NUMA-include/linux/gfp.h, line 466 UMA-include/linux/gfp.h?v=4.7, line 476 |
| alloc_page(mask) | 是前者在order = 0情況下的簡化形式，只分配一頁 | include/linux/gfp.h?v=4.7, line 483 |
| get_zeroed_page(mask) | 分配一頁並返回一個page例項，頁對應的記憶體填充0（所有其他函式，分配之後頁的內容是未定義的） | mm/page_alloc.c?v=4.7, line 3900 |
| __get_free_pages(mask, order) __get_free_page(mask) |
工作方式與上述函式相同，但返回分配記憶體塊的虛擬地址，而不是page例項 | |
| get_dma_pages(gfp_mask, order) | 用來獲得適用於DMA的頁. | include/linux/gfp.h?v=4.7, line 503 |
在空閒記憶體無法滿足請求以至於分配失敗的情況下，所有上述函式都返回空指標(比如alloc_pages和alloc_page)或者0(比如get_zeroed_page、__get_free_pages和__get_free_page).
因此核心在各次分配之後都必須檢查返回的結果. 這種慣例與設計得很好的使用者層應用程式沒什麼不同, 但在核心中忽略檢查會導致嚴重得多的故障
核心除了夥伴系統函式之外, 還提供了其他記憶體管理函式. 它們以夥伴系統為基礎, 但並不屬於夥伴分配器自身. 這些函式包括vmalloc和vmalloc_32, 使用頁表將不連續的記憶體對映到核心地址空間中, 使之看上去是連續的.
還有一組kmalloc型別的函式, 用於分配小於一整頁的記憶體區. 其實現.
釋放函式
有4個函式用於釋放不再使用的頁，與所述函式稍有不同
| 記憶體釋放函式 | 描述 |
|---|---|
| free_page(struct page ) free_pages(struct page , order) |
用於將一個或2order頁返回給記憶體管理子系統。記憶體區的起始地址由指向該記憶體區的第一個page例項的指標表示 |
| __free_page(addr) __free_pages(addr, order) |
類似於前兩個函式，但在表示需要釋放的記憶體區時，使用了虛擬記憶體地址而不是page例項 |
4.2 分配掩碼(gfp_mask標誌)
4.2.1 分配掩碼
前述所有函式中強制使用的mask引數，到底是什麼語義?
我們知道Linux將記憶體劃分為記憶體域. 核心提供了所謂的記憶體域修飾符(zone modifier)(在掩碼的最低4個位元位定義), 來指定從哪個記憶體域分配所需的頁.
核心使用巨集的方式定義了這些掩碼, 一個掩碼的定義被劃分為3個部分進行定義, 我們會逐步展開來講解, 參見include/linux/gfp.h?v=4.7, line 12~374, 共計26個掩碼資訊, 因此後面__GFP_BITS_SHIFT = 26.
4.2.2 掩碼分類
Linux中這些掩碼標誌gfp_mask分為3種類型 :
| 型別 | 描述 |
|---|---|
| 區描述都符 | 核心把實體記憶體分為多個區, 每個區用於不同的目的, 區描述符指明到底從這些區中的哪一區進行分配 |
| 行為修飾符 | 表示核心應該如何分配所需的記憶體. 在某些特定情況下, 只能使用某些特定的方法分配記憶體 |
| 型別標誌 | 組合了行為修飾符和區描述符, 將這些可能用到的組合歸納為不同型別 |
4.2.3 核心中掩碼的定義
核心中的定義方式
// http://lxr.free-electrons.com/source/include/linux/gfp.h?v=4.7
/* line 12 ~ line 44 第一部分
* 定義可掩碼所在位的資訊, 每個掩碼對應一位為1
* 定義形式為 #define ___GFP_XXX 0x01u
*/
/* Plain integer GFP bitmasks. Do not use this directly. */
#define ___GFP_DMA 0x01u
#define ___GFP_HIGHMEM 0x02u
#define ___GFP_DMA32 0x04u
#define ___GFP_MOVABLE 0x08u
/* ...... */
/* line 46 ~ line 192 第二部分
* 定義掩碼和MASK資訊, 第二部分的某些巨集可能是第一部分一個或者幾個的組合
* 定義形式為 #define __GFP_XXX ((__force gfp_t)___GFP_XXX)
*/
#define __GFP_DMA ((__force gfp_t)___GFP_DMA)
#define __GFP_HIGHMEM ((__force gfp_t)___GFP_HIGHMEM)
#define __GFP_DMA32 ((__force gfp_t)___GFP_DMA32)
#define __GFP_MOVABLE ((__force gfp_t)___GFP_MOVABLE) /* ZONE_MOVABLE allowed */
#define GFP_ZONEMASK (__GFP_DMA|__GFP_HIGHMEM|__GFP_DMA32|__GFP_MOVABLE)
/* line 194 ~ line 260 第三部分
* 定義掩碼
* 定義形式為 #define GFP_XXX __GFP_XXX
*/
#define GFP_DMA __GFP_DMA
#define GFP_DMA32 __GFP_DMA32其中GFP縮寫的意思為獲取空閒頁(get free page), __GFP_MOVABLE不表示實體記憶體域, 但通知核心應在特殊的虛擬記憶體域ZONE_MOVABLE進行相應的分配.
定義掩碼位
我們首先來看第一部分, 核心原始碼中定義在include/linux/gfp.h?v=4.7, line 18 ~ line 44, 共計26個掩碼資訊.
/* Plain integer GFP bitmasks. Do not use this directly. */
// 區域修飾符
#define ___GFP_DMA 0x01u
#define ___GFP_HIGHMEM 0x02u
#define ___GFP_DMA32 0x04u
// 行為修飾符
#define ___GFP_MOVABLE 0x08u /* 頁是可移動的 */
#define ___GFP_RECLAIMABLE 0x10u /* 頁是可回收的 */
#define ___GFP_HIGH 0x20u /* 應該訪問緊急分配池？ */
#define ___GFP_IO 0x40u /* 可以啟動物理IO？ */
#define ___GFP_FS 0x80u /* 可以呼叫底層檔案系統？ */
#define ___GFP_COLD 0x100u /* 需要非快取的冷頁 */
#define ___GFP_NOWARN 0x200u /* 禁止分配失敗警告 */
#define ___GFP_REPEAT 0x400u /* 重試分配，可能失敗 */
#define ___GFP_NOFAIL 0x800u /* 一直重試，不會失敗 */
#define ___GFP_NORETRY 0x1000u /* 不重試，可能失敗 */
#define ___GFP_MEMALLOC 0x2000u /* 使用緊急分配連結串列 */
#define ___GFP_COMP 0x4000u /* 增加複合頁元資料 */
#define ___GFP_ZERO 0x8000u /* 成功則返回填充位元組0的頁 */
// 型別修飾符
#define ___GFP_NOMEMALLOC 0x10000u /* 不使用緊急分配連結串列 */
#define ___GFP_HARDWALL 0x20000u /* 只允許在程序允許執行的CPU所關聯的結點分配記憶體 */
#define ___GFP_THISNODE 0x40000u /* 沒有備用結點，沒有策略 */
#define ___GFP_ATOMIC 0x80000u /* 用於原子分配，在任何情況下都不能中斷 */
#define ___GFP_ACCOUNT 0x100000u
#define ___GFP_NOTRACK 0x200000u
#define ___GFP_DIRECT_RECLAIM 0x400000u
#define ___GFP_OTHER_NODE 0x800000u
#define ___GFP_WRITE 0x1000000u
#define ___GFP_KSWAPD_RECLAIM 0x2000000u定義掩碼
然後第二部分, 相對而言每一個巨集又被重新定義如下, 參見include/linux/gfp.h?v=4.7, line 46 ~ line 192
/*
* Physical address zone modifiers (see linux/mmzone.h - low four bits)
*
* Do not put any conditional on these. If necessary modify the definitions
* without the underscores and use them consistently. The definitions here may
* be used in bit comparisons.
* 定義區描述符
*/
#define __GFP_DMA ((__force gfp_t)___GFP_DMA)
#define __GFP_HIGHMEM ((__force gfp_t)___GFP_HIGHMEM)
#define __GFP_DMA32 ((__force gfp_t)___GFP_DMA32)
#define __GFP_MOVABLE ((__force gfp_t)___GFP_MOVABLE) /* ZONE_MOVABLE allowed */
#define GFP_ZONEMASK (__GFP_DMA|__GFP_HIGHMEM|__GFP_DMA32|__GFP_MOVABLE)
/*
* Page mobility and placement hints
*
* These flags provide hints about how mobile the page is. Pages with similar
* mobility are placed within the same pageblocks to minimise problems due
* to external fragmentation.
*
* __GFP_MOVABLE (also a zone modifier) indicates that the page can be
* moved by page migration during memory compaction or can be reclaimed.
*
* __GFP_RECLAIMABLE is used for slab allocations that specify
* SLAB_RECLAIM_ACCOUNT and whose pages can be freed via shrinkers.
*
* __GFP_WRITE indicates the caller intends to dirty the page. Where possible,
* these pages will be spread between local zones to avoid all the dirty
* pages being in one zone (fair zone allocation policy).
*
* __GFP_HARDWALL enforces the cpuset memory allocation policy.
*
* __GFP_THISNODE forces the allocation to be satisified from the requested
* node with no fallbacks or placement policy enforcements.
*
* __GFP_ACCOUNT causes the allocation to be accounted to kmemcg (only relevant
* to kmem allocations).
*/
#define __GFP_RECLAIMABLE ((__force gfp_t)___GFP_RECLAIMABLE)
#define __GFP_WRITE ((__force gfp_t)___GFP_WRITE)
#define __GFP_HARDWALL ((__force gfp_t)___GFP_HARDWALL)
#define __GFP_THISNODE ((__force gfp_t)___GFP_THISNODE)
#define __GFP_ACCOUNT ((__force gfp_t)___GFP_ACCOUNT)
/*
* Watermark modifiers -- controls access to emergency reserves
*
* __GFP_HIGH indicates that the caller is high-priority and that granting
* the request is necessary before the system can make forward progress.
* For example, creating an IO context to clean pages.
*
* __GFP_ATOMIC indicates that the caller cannot reclaim or sleep and is
* high priority. Users are typically interrupt handlers. This may be
* used in conjunction with __GFP_HIGH
*
* __GFP_MEMALLOC allows access to all memory. This should only be used when
* the caller guarantees the allocation will allow more memory to be freed
* very shortly e.g. process exiting or swapping. Users either should
* be the MM or co-ordinating closely with the VM (e.g. swap over NFS).
*
* __GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves.
* This takes precedence over the __GFP_MEMALLOC flag if both are set.
*/
#define __GFP_ATOMIC ((__force gfp_t)___GFP_ATOMIC)
#define __GFP_HIGH ((__force gfp_t)___GFP_HIGH)
#define __GFP_MEMALLOC ((__force gfp_t)___GFP_MEMALLOC)
#define __GFP_NOMEMALLOC ((__force gfp_t)___GFP_NOMEMALLOC)
/*
* Reclaim modifiers
*
* __GFP_IO can start physical IO.
*
* __GFP_FS can call down to the low-level FS. Clearing the flag avoids the
* allocator recursing into the filesystem which might already be holding
* locks.
*
* __GFP_DIRECT_RECLAIM indicates that the caller may enter direct reclaim.
* This flag can be cleared to avoid unnecessary delays when a fallback
* option is available.
*
* __GFP_KSWAPD_RECLAIM indicates that the caller wants to wake kswapd when
* the low watermark is reached and have it reclaim pages until the high
* watermark is reached. A caller may wish to clear this flag when fallback
* options are available and the reclaim is likely to disrupt the system. The
* canonical example is THP allocation where a fallback is cheap but
* reclaim/compaction may cause indirect stalls.
*
* __GFP_RECLAIM is shorthand to allow/forbid both direct and kswapd reclaim.
*
* __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
* _might_ fail. This depends upon the particular VM implementation.
*
* __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
* cannot handle allocation failures. New users should be evaluated carefully
* (and the flag should be used only when there is no reasonable failure
* policy) but it is definitely preferable to use the flag rather than
* opencode endless loop around allocator.
*
* __GFP_NORETRY: The VM implementation must not retry indefinitely and will
* return NULL when direct reclaim and memory compaction have failed to allow
* the allocation to succeed. The OOM killer is not called with the current
* implementation.
*/
#define __GFP_IO ((__force gfp_t)___GFP_IO)
#define __GFP_FS ((__force gfp_t)___GFP_FS)
#define __GFP_DIRECT_RECLAIM ((__force gfp_t)___GFP_DIRECT_RECLAIM) /* Caller can reclaim */
#define __GFP_KSWAPD_RECLAIM ((__force gfp_t)___GFP_KSWAPD_RECLAIM) /* kswapd can wake */
#define __GFP_RECLAIM ((__force gfp_t)(___GFP_DIRECT_RECLAIM|___GFP_KSWAPD_RECLAIM))
#define __GFP_REPEAT ((__force gfp_t)___GFP_REPEAT)
#define __GFP_NOFAIL ((__force gfp_t)___GFP_NOFAIL)
#define __GFP_NORETRY ((__force gfp_t)___GFP_NORETRY)
/*
* Action modifiers
*
* __GFP_COLD indicates that the caller does not expect to be used in the near
* future. Where possible, a cache-cold page will be returned.
*
* __GFP_NOWARN suppresses allocation failure reports.
*
* __GFP_COMP address compound page metadata.
*
* __GFP_ZERO returns a zeroed page on success.
*
* __GFP_NOTRACK avoids tracking with kmemcheck.
*
* __GFP_NOTRACK_FALSE_POSITIVE is an alias of __GFP_NOTRACK. It's a means of
* distinguishing in the source between false positives and allocations that
* cannot be supported (e.g. page tables).
*
* __GFP_OTHER_NODE is for allocations that are on a remote node but that
* should not be accounted for as a remote allocation in vmstat. A
* typical user would be khugepaged collapsing a huge page on a remote
* node.
*/
#define __GFP_COLD ((__force gfp_t)___GFP_COLD)
#define __GFP_NOWARN ((__force gfp_t)___GFP_NOWARN)
#define __GFP_COMP ((__force gfp_t)___GFP_COMP)
#define __GFP_ZERO ((__force gfp_t)___GFP_ZERO)
#define __GFP_NOTRACK ((__force gfp_t)___GFP_NOTRACK)
#define __GFP_NOTRACK_FALSE_POSITIVE (__GFP_NOTRACK)
#define __GFP_OTHER_NODE ((__force gfp_t)___GFP_OTHER_NODE)
/* Room for N __GFP_FOO bits */
#define __GFP_BITS_SHIFT 26
#define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))給出的常數，其中一些很少使用，因此我不會討論。其中最重要的一些常數語義如下所示
其中在開始的位置定義了對應的區修飾符, 定義在include/linux/gfp.h?v=4.7, line 46 ~ line 57
| 區修飾符標誌 | 描述 |
|---|---|
| __GFP_DMA | 從ZONE_DMA中分配記憶體 |
| __GFP_HIGHMEM | 從ZONE_HIGHMEM活ZONE_NORMAL中分配記憶體 |
| __GFP_DMA32 | 從ZONE_DMA32中分配記憶體 |
| __GFP_MOVABLE | 從__GFP_MOVABLE中分配記憶體 |
其次還定義了我們程式和函式中所需要的掩碼MASK的資訊, 由於其中__GFP_DMA, __GFP_DMA32, __GFP_HIGHMEM, __GFP_MOVABLE是在記憶體中分別有對應的記憶體域資訊, 因此我們定義了記憶體域的掩碼GFP_ZONEMASK, 參見include/linux/gfp.h?v=4.7, line 57
#define GFP_ZONEMASK (__GFP_DMA|__GFP_HIGHMEM|__GFP_DMA32|__GFP_MOVABLE)接著核心定義了行為修飾符
/* __GFP_WAIT表示分配記憶體的請求可以中斷。也就是說，排程器在該請求期間可隨意選擇另一個過程執行，或者該請求可以被另一個更重要的事件中斷. 分配器還可以在返回記憶體之前, 在佇列上等待一個事件(相關程序會進入睡眠狀態).
雖然名字相似，但__GFP_HIGH與__GFP_HIGHMEM毫無關係，請不要弄混這兩者
| 行為修飾符 | 描述 |
|---|---|
| __GFP_RECLAIMABLE __GFP_MOVABLE |
是頁遷移機制所需的標誌. 顧名思義，它們分別將分配的記憶體標記為可回收的或可移動的。這影響從空閒列表的哪個子表獲取記憶體 |
| __GFP_WRITE | |
| __GFP_HARDWALL | 只在NUMA系統上有意義. 它限制只在分配到當前程序的各個CPU所關聯的結點分配記憶體。如果程序允許在所有CPU上執行（預設情況），該標誌是無意義的。只有程序可以執行的CPU受限時，該標誌才有效果 |
| __GFP_THISNODE | 也只在NUMA系統上有意義。如果設定該位元位，則記憶體分配失敗的情況下不允許使用其他結點作為備用，需要保證在當前結點或者明確指定的結點上成功分配記憶體 |
| __GFP_ACCOUNT | |
| __GFP_ATOMIC | |
| __GFP_HIGH | 如果請求非常重要, 則設定__GFP_HIGH，即核心急切地需要記憶體時。在分配記憶體失敗可能給核心帶來嚴重後果時(比如威脅到系統穩定性或系統崩潰), 總是會使用該標誌 |
| __GFP_MEMALLOC | |
| __GFP_NOMEMALLOC | |
| __GFP_IO | 說明在查詢空閒記憶體期間核心可以進行I/O操作. 實際上, 這意味著如果核心在記憶體分配期間換出頁, 那麼僅當設定該標誌時, 才能將選擇的頁寫入硬碟 |
| __GFP_FS | 允許核心執行VFS操作. 在與VFS層有聯絡的核心子系統中必須禁用, 因為這可能引起迴圈遞迴呼叫. |
| __GFP_DIRECT_RECLAIM | |
| __GFP_KSWAPD_RECLAIM | |
| __GFP_RECLAIM | |
| __GFP_REPEAT | 在分配失敗後自動重試，但在嘗試若干次之後會停止 |
| __GFP_NOFAIL | 在分配失敗後一直重試，直至成功 |
| __GFP_NORETRY | 在分配失敗後不重試，因此可能分配失敗 |
| __GFP_COLD | 如果需要分配不在CPU快取記憶體中的“冷”頁時，則設定__GFP_COLD |
| __GFP_NOWARN | 在分配失敗時禁止核心故障警告。在極少數場合該標誌有用 |
| __GFP_COMP | 新增混合頁元素, 在hugetlb的程式碼內部使用 |
| __GFP_ZERO | 在分配成功時，將返回填充位元組0的頁 |
| __GFP_NOTRACK | |
| __GFP_NOTRACK_FALSE_POSITIVE __GFP_NOTRACK |
|
| __GFP_OTHER_NODE |
那自然還有__GFP_BITS_SHIFT來表示我們所有的掩碼位, 由於我們共計26個掩碼位
/* Room for N __GFP_FOO bits */
#define __GFP_BITS_SHIFT 26
#define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))可以同時指定這些分配標誌, 例如
ptr = kmalloc(size, __GFP_IO | __GFP_FS);說明頁分配器(最終會呼叫alloc_page)在分配時可以執行I/O, 在必要時還可以執行檔案系統操作. 這就讓核心有很大的自由度, 以便它儘可能找到空閒的記憶體來滿足分配請求. 大多數分配器都會執行這些修飾符, 但一般不是這樣直接指定, 而是將這些行為描述符標誌進行分組, 即型別標誌
掩碼分組
最後來看第三部分, 由於這些標誌幾乎總是組合使用，核心作了一些分組，包含了用於各種標準情形的適當的標誌. 稱之為型別標誌, 定義在include/linux/gfp.h?v=4.7, lien 194 ~ line 258
型別標誌指定所需的行為和區描述符以安城特殊型別的處理, 正因為這一點, 核心總是趨於使用正確的型別標誌, 而不是一味地指定它可能用到的多種描述符. 這麼做既簡單又不容易出錯誤.
如果有可能的話, 在記憶體管理子系統之外, 總是把下列分組之一用於記憶體分配. 在核心原始碼中, 雙下劃線通常用於內部資料和定義. 而這些預定義的分組名沒有雙下劃線字首, 點從側面驗證了上述說法.
#define GFP_ATOMIC (__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM)
#define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS)
#define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM)
#define GFP_NOIO (__GFP_RECLAIM)
#define GFP_NOFS (__GFP_RECLAIM | __GFP_IO)
#define GFP_TEMPORARY (__GFP_RECLAIM | __GFP_IO | __GFP_FS | \
__GFP_RECLAIMABLE)
#define GFP_USER (__GFP_RECLAIM | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
#define GFP_DMA __GFP_DMA
#define GFP_DMA32 __GFP_DMA32
#define GFP_HIGHUSER (GFP_USER | __GFP_HIGHMEM)
#define GFP_HIGHUSER_MOVABLE (GFP_HIGHUSER | __GFP_MOVABLE)
#define GFP_TRANSHUGE ((GFP_HIGHUSER_MOVABLE | __GFP_COMP | \
__GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_NOWARN) & \
~__GFP_RECLAIM)
/* Convert GFP flags to their corresponding migrate type */
#define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)
#define GFP_MOVABLE_SHIFT 3
| 掩碼組 | 描述 |
|---|---|
| GFP_ATOMIC | 用於原子分配，在任何情況下都不能中斷, 可能使用緊急分配連結串列中的記憶體, 這個標誌用在中斷處理程式, 下半部, 持有自旋鎖以及其他不能睡眠的地方 |
| GFP_KERNEL | 這是一種常規的分配方式, 可能會阻塞. 這個標誌在睡眠安全時用在程序的長下文程式碼中. 為了獲取呼叫者所需的記憶體, 核心會盡力而為. 這個標誌應該是首選標誌 |
| GFP_KERNEL_ACCOUNT | |
| GFP_NOWAIT | 與GFP_ATOMIC類似, 不同之處在於, 呼叫不會退給緊急記憶體池, 這就增加了記憶體分配失敗的可能性 |
| GFP_NOIO | 這種分配可以阻塞, 但不會啟動磁碟I/O, 這個標誌在不能引發更多的磁碟I/O時阻塞I/O程式碼, 這可能導致令人不愉快的遞迴 |
| GFP_NOFS | 這種分配在必要時可以阻塞, 但是也可能啟動磁碟, 但是不會啟動檔案系統操作, 這個標誌在你不鞥在啟動另一個檔案系統操作時, 用在檔案系統部分的程式碼中 |
| GFP_TEMPORARY | |
| GFP_USER | 這是一種常規的分配方式, 可能會阻塞. 這個標誌用於為使用者空間程序分配記憶體時使用 |
| GFP_DMA | |
| GFP_DMA32 | 用於分配適用於DMA的記憶體, 當前是__GFP_DMA的同義詞, GFP_DMA32也是__GFP_GMA32的同義詞 |
| GFP_HIGHUSER | 是GFP_USER的一個擴充套件, 也用於使用者空間. 它允許分配無法直接對映的高階記憶體. 使用高階記憶體頁是沒有壞處的，因為使用者過程的地址空間總是通過非線性頁表組織的 |
| GFP_HIGHUSER_MOVABLE | 用途類似於GFP_HIGHUSER，但分配將從虛擬記憶體域ZONE_MOVABLE進行 |
| GFP_TRANSHUGE |
- 其中GFP_NOIO和GFP_NOFS, 分別明確禁止I/O操作和訪問VFS層, 但同時設定了__GFP_RECLAIM，因此可以被回收
- 而GFP_KERNEL和GFP_USER. 分別是核心和使用者分配的預設設定。二者的失敗不會立即威脅系統穩定性, GFP_KERNEL絕對是核心原始碼中最常使用的標誌 |
最後核心設定了碎片管理的可移動依據組織頁的MASK資訊GFP_MOVABLE_MASK, 參見include/linux/gfp.h?v=4.7, line 262
/* Convert GFP flags to their corresponding migrate type */
#define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)
#define GFP_MOVABLE_SHIFT 3在你編寫的絕大多數程式碼中, 用麼用到的是GFP_KERNEL, 要麼是GFP_ATOMIC, 當然各個型別標誌也均有其應用場景
| 情形 | 相應標誌 |
|---|---|
| 程序上下文, 可以睡眠 | 使用GFP_KERNEL |
| 程序上下文, 不可以睡眠 | 使用GFP_KERNEL, 在你睡眠之前或之後以GFP_KERNEL執行記憶體分配 |
| 中斷處理程式 | 使用GFP_ATMOIC |
| 軟中斷 | 使用GFP_ATMOIC |
| tasklet | 使用GFP_ATMOIC |
| 需要用於DMA的記憶體, 可以睡眠 | 使用(GFP_DMA GFP_KERNEL) |
| 需要用於DMA的記憶體, 不可以睡眠 | 使用(GFP_DMA GFP_ATOMIC), 或在你睡眠之前執行記憶體分配 |
4.2.5 總結
我們從註釋中找到這樣的資訊, 可以作為參考
bit result
=================
0x0 => NORMAL
0x1 => DMA or NORMAL
0x2 => HIGHMEM or NORMAL
0x3 => BAD (DMA+HIGHMEM)
0x4 => DMA32 or DMA or NORMAL
0x5 => BAD (DMA+DMA32)
0x6 => BAD (HIGHMEM+DMA32)
0x7 => BAD (HIGHMEM+DMA32+DMA)
0x8 => NORMAL (MOVABLE+0)
0x9 => DMA or NORMAL (MOVABLE+DMA)
0xa => MOVABLE (Movable is valid only if HIGHMEM is set too)
0xb => BAD (MOVABLE+HIGHMEM+DMA)
0xc => DMA32 (MOVABLE+DMA32)
0xd => BAD (MOVABLE+DMA32+DMA)
0xe => BAD (MOVABLE+DMA32+HIGHMEM)
0xf => BAD (MOVABLE+DMA32+HIGHMEM+DMA)
GFP_ZONES_SHIFT must be <= 2 on 32 bit platforms.很有趣的一點是，沒有__GFP_NORMAL常數，而記憶體分配的主要負擔卻落到ZONE_NORMAL記憶體域
核心考慮到這一點, 提供了一個函式gfp_zone來計算與給定分配標誌相容的最高記憶體域. 那麼記憶體分配可以從該記憶體域或更低的記憶體域進行, 該函式定義在include/linux/gfp.h?v=4.7, line 394
#if defined(CONFIG_ZONE_DEVICE) && (MAX_NR_ZONES-1) <= 4
/* ZONE_DEVICE is not a valid GFP zone specifier */
#define GFP_ZONES_SHIFT 2
#else
#define GFP_ZONES_SHIFT ZONES_SHIFT
#endif
#if 16 * GFP_ZONES_SHIFT > BITS_PER_LONG
#error GFP_ZONES_SHIFT too large to create GFP_ZONE_TABLE integer
#endif由於記憶體域修飾符的解釋方式不是那麼直觀, 表3-7給出了該函式結果的一個例子, 其中DMA和DMA32記憶體域相同. 假定在下文中沒有設定__GFP_MOVABLE修飾符.
| 修飾符 | 掃描的記憶體域 |
|---|---|
| 無 | ZONE_NORMAL、ZONE_DMA |
| __GFP_DMA | ZONE_DMA |
| __GFP_DMA & __GFP_HIGHMEM | ZONE_DMA |
| __GFP_HIGHMEM | ZONE_HIGHMEM、ZONE_NORMAL、ZONE_DMA |
- 如果__GFP_DMA和__GFP_HIGHMEM都沒有設定, 則首先掃描ZONE_NORMAL, 後面是ZONE_DMA
- 如果設定了__GFP_HIGHMEM沒有設定__GFP_DMA，則結果是從ZONE_HIGHMEM開始掃描所有3個記憶體域。
- 如果設定了__GFP_DMA，那麼__GFP_HIGHMEM設定與否沒有關係. 只有ZONE_DMA用於3種情形. 這是合理的, 因為同時使用__GFP_HIGHMEM和__GFP_DMA沒有意義. 高階記憶體從來都不適用於DMA
設定__GFP_MOVABLE不會影響核心的決策，除非它與__GFP_HIGHMEM同時指定. 在這種情況下, 會使用特殊的虛擬記憶體域ZONE_MOVABLE滿足記憶體分配請求. 對前文描述的核心的反碎片策略而言, 這種行為是必要的.
除了記憶體域修飾符之外, 掩碼中還可以設定一些標誌.
下圖中給出了掩碼的佈局，以及與各個位元位置關聯的常數. __GFP_DMA32出現了幾次，因為它可能位於不同的地方.
與記憶體域修飾符相反, 這些額外的標誌並不限制從哪個實體記憶體段分配記憶體, 但確實可以改變分配器的行為. 例如, 它們可以修改查詢空閒記憶體時的積極程度.
4.3 分配頁
4.3.1 記憶體分配統一到alloc_pages介面
通過使用標誌、記憶體域修飾符和各個分配函式，核心提供了一種非常靈活的記憶體分配體系.儘管如此, 所有介面函式都可以追溯到一個簡單的基本函式(alloc_pages_node)
分配單頁的函式alloc_page和__get_free_page, 還有__get_dma_pages是藉助於巨集定義的.
// http://lxr.free-electrons.com/source/include/linux/gfp.h?v=4.7#L483
#define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0)
// http://lxr.free-electrons.com/source/include/linux/gfp.h?v=4.7#L500
#define __get_free_page(gfp_mask) \
__get_free_pages((gfp_mask), 0)`
// http://lxr.free-electrons.com/source/include/linux/gfp.h?v=4.7#L503
#define __get_dma_pages(gfp_mask, order) \
__get_free_pages((gfp_mask) | GFP_DMA, (order))get_zeroed_page的實現也沒什麼困難, 對__get_free_pages使用__GFP_ZERO標誌，即可分配填充位元組0的頁. 再返回與頁關聯的記憶體區地址即可.
// http://lxr.free-electrons.com/source/mm/page_alloc.c?v=4.7#L3900
unsigned long get_zeroed_page(gfp_t gfp_mask)
{
return __get_free_pages(gfp_mask | __GFP_ZERO, 0);
}
EXPORT_SYMBOL(get_zeroed_page);__get_free_pages呼叫alloc_pages完成記憶體分配, 而alloc_pages又藉助於alloc_pages_node
__get_free_pages函式的定義在mm/page_alloc.c?