本文為原創，轉載請注明：http://www.cnblogs.com/tolimit/
直接內存回收中的等待隊列
內存回收詳解見linux內存源碼分析 - 內存回收(整體流程)，在直接內存回收過程中，有可能會造成當前需要分配內存的進程被加入一個等待隊列，當整個node的空閑頁數量滿足要求時，由kswapd喚醒它重新獲取內存。這個等待隊列頭就是node結點描述符pgdat中的pfmemalloc_wait。如果當前進程加入到了pgdat->pfmemalloc_wait這個等待隊列中，那么進程就不會進行直接內存回收，而是由kswapd喚醒后直接進行內存分配。
直接內存回收執行路徑是：
__alloc_pages_slowpath() -> __alloc_pages_direct_reclaim() -> __perform_reclaim() -> try_to_free_pages() -> do_try_to_free_pages() -> shrink_zones() -> shrink_zone()
在__alloc_pages_slowpath()中可能喚醒了所有node的kswapd內核線程，也可能沒有喚醒，每個node的kswapd是否在__alloc_pages_slowpath()中被喚醒有兩個條件：
- 分配標志中沒有__GFP_NO_KSWAPD，只有在透明大頁的分配過程中會有這個標志。
- node中有至少一個zone的空閑頁框沒有達到 空閑頁框數量 >= high閥值 + 1 << order + 保留內存，或者有至少一個zone需要進行內存壓縮，這兩種情況node的kswapd都會被喚醒。
而在kswapd中會對node中每一個不平衡的zone進行內存回收，直到所有zone都滿足 zone分配頁框后剩余的頁框數量 > 此zone的high閥值 + 此zone保留的頁框數量。kswapd就會停止內存回收，然后喚醒在等待隊列的進程。
之后進程由於內存不足，對zonelist進行直接回收時，會調用到try_to_free_pages()，在這個函數內，決定了進程是否加入到node結點的pgdat->pfmemalloc_wait這個等待隊列中，如下：
unsigned long try_to_free_pages(struct zonelist *zonelist, int order, gfp_t gfp_mask, nodemask_t *nodemask) { unsigned long nr_reclaimed; struct scan_control sc = { /* 打算回收32個頁框 */ .nr_to_reclaim = SWAP_CLUSTER_MAX, .gfp_mask = (gfp_mask = memalloc_noio_flags(gfp_mask)), /* 本次內存分配的order值 */ .order = order, /* 允許進行回收的node掩碼 */ .nodemask = nodemask, /* 優先級為默認的12 */ .priority = DEF_PRIORITY, /* 與/proc/sys/vm/laptop_mode文件有關 * laptop_mode為0，則允許進行回寫操作，即使允許回寫，直接內存回收也不能對臟文件頁進行回寫 * 不過允許回寫時，可以對非文件頁進行回寫 */ .may_writepage = !laptop_mode, /* 允許進行unmap操作 */ .may_unmap = 1, /* 允許進行非文件頁的操作 */ .may_swap = 1, }; /* * Do not enter reclaim if fatal signal was delivered while throttled. * 1 is returned so that the page allocator does not OOM kill at this * point. */ /* 當zonelist中獲取到的第一個node平衡，則返回，如果獲取到的第一個node不平衡，則將當前進程加入到pgdat->pfmemalloc_wait這個等待隊列中 * 這個等待隊列會在kswapd進行內存回收時，如果讓node平衡了，則會喚醒這個等待隊列中的進程 * 判斷node平衡的標准: * 此node的ZONE_DMA和ZONE_NORMAL的總共空閑頁框數量 是否大於 此node的ZONE_DMA和ZONE_NORMAL的平均min閥值數量，大於則說明node平衡 * 加入pgdat->pfmemalloc_wait的情況 * 1.如果分配標志禁止了文件系統操作，則將要進行內存回收的進程設置為TASK_INTERRUPTIBLE狀態，然后加入到node的pgdat->pfmemalloc_wait，並且會設置超時時間為1s * 2.如果分配標志沒有禁止了文件系統操作，則將要進行內存回收的進程加入到node的pgdat->pfmemalloc_wait，並設置為TASK_KILLABLE狀態，表示允許 TASK_UNINTERRUPTIBLE 響應致命信號的狀態 * 返回真，表示此進程加入過pgdat->pfmemalloc_wait等待隊列，並且已經被喚醒 * 返回假，表示此進程沒有加入過pgdat->pfmemalloc_wait等待隊列 */ if (throttle_direct_reclaim(gfp_mask, zonelist, nodemask)) return 1; trace_mm_vmscan_direct_reclaim_begin(order, sc.may_writepage, gfp_mask); /* 進行內存回收，有三種情況到這里 * 1.當前進程為內核線程 * 2.最優node是平衡的，當前進程沒有加入到pgdat->pfmemalloc_wait中 * 3.當前進程接收到了kill信號 */ nr_reclaimed = do_try_to_free_pages(zonelist, &sc); trace_mm_vmscan_direct_reclaim_end(nr_reclaimed); return nr_reclaimed; }
主要通過throttle_direct_reclaim()函數判斷是否加入到pgdat->pfmemalloc_wait等待隊列中，主要看此函數：
/* 當zonelist中第一個node平衡，則返回，如果node不平衡，則將當前進程加入到pgdat->pfmemalloc_wait這個等待隊列中 * 這個等待隊列會在kswapd進行內存回收時，如果讓node平衡了，則會喚醒這個等待隊列中的進程 * 判斷node平衡的標准: * 此node的ZONE_DMA和ZONE_NORMAL的總共空閑頁框數量 是否大於 此node的ZONE_DMA和ZONE_NORMAL的平均min閥值數量，大於則說明node平衡 * 加入pgdat->pfmemalloc_wait的情況 * 1.如果分配標志禁止了文件系統操作，則將要進行內存回收的進程設置為TASK_INTERRUPTIBLE狀態，然后加入到node的pgdat->pfmemalloc_wait，並且會設置超時時間為1s * 2.如果分配標志沒有禁止了文件系統操作，則將要進行內存回收的進程加入到node的pgdat->pfmemalloc_wait，並設置為TASK_KILLABLE狀態，表示允許 TASK_UNINTERRUPTIBLE 響應致命信號的狀態 */ static bool throttle_direct_reclaim(gfp_t gfp_mask, struct zonelist *zonelist, nodemask_t *nodemask) { struct zoneref *z; struct zone *zone; pg_data_t *pgdat = NULL; /* 如果標記了PF_KTHREAD，表示此進程是一個內核線程，則不會往下執行 */ if (current->flags & PF_KTHREAD) goto out; /* 此進程已經接收到了kill信號，准備要被殺掉了 */ if (fatal_signal_pending(current)) goto out;
/* 遍歷zonelist，但是里面只會在獲取到第一個pgdat時就跳出 */ for_each_zone_zonelist_nodemask(zone, z, zonelist, gfp_mask, nodemask) { /* 只遍歷ZONE_NORMAL和ZONE_DMA區 */ if (zone_idx(zone) > ZONE_NORMAL) continue; /* 獲取zone對應的node */ pgdat = zone->zone_pgdat; /* 判斷node是否平衡，如果平衡，則返回真 * 如果不平衡，如果此node的kswapd沒有被喚醒，則喚醒，並且這里喚醒kswapd只會對ZONE_NORMAL以下的zone進行內存回收 * node是否平衡的判斷標准是: * 此node的ZONE_DMA和ZONE_NORMAL的總共空閑頁框數量 是否大於 此node的ZONE_DMA和ZONE_NORMAL的平均min閥值數量，大於則說明node平衡 */ if (pfmemalloc_watermark_ok(pgdat)) goto out; break; } if (!pgdat) goto out; count_vm_event(PGSCAN_DIRECT_THROTTLE); if (!(gfp_mask & __GFP_FS)) { /* 如果分配標志禁止了文件系統操作，則將要進行內存回收的進程設置為TASK_INTERRUPTIBLE狀態，然后加入到node的pgdat->pfmemalloc_wait，並且會設置超時時間為1s * 1.pfmemalloc_watermark_ok(pgdat)為真時被喚醒，而1s沒超時，返回剩余timeout(jiffies) * 2.睡眠超過1s時會喚醒，而pfmemalloc_watermark_ok(pgdat)此時為真，返回1 * 3.睡眠超過1s時會喚醒，而pfmemalloc_watermark_ok(pgdat)此時為假，返回0 * 4.接收到信號被喚醒，返回-ERESTARTSYS */ wait_event_interruptible_timeout(pgdat->pfmemalloc_wait, pfmemalloc_watermark_ok(pgdat), HZ); goto check_pending; } /* Throttle until kswapd wakes the process */ /* 如果分配標志沒有禁止了文件系統操作，則將要進行內存回收的進程加入到node的pgdat->pfmemalloc_wait，並設置為TASK_KILLABLE狀態，表示允許 TASK_UNINTERRUPTIBLE 響應致命信號的狀態 * 這些進程在兩種情況下被喚醒 * 1.pfmemalloc_watermark_ok(pgdat)為真時 * 2.接收到致命信號時 */ wait_event_killable(zone->zone_pgdat->pfmemalloc_wait, pfmemalloc_watermark_ok(pgdat)); check_pending: /* 如果加入到了pgdat->pfmemalloc_wait后被喚醒，就會執行到這 */ /* 喚醒后再次檢查當前進程是否接受到了kill信號，准備退出 */ if (fatal_signal_pending(current)) return true; out: return false; }
有四點需要注意：
- 當前進程已經接收到kill信號，則不會將其加入到pgdat->pfmemalloc_wait中。
- 只獲取第一個node，也就是當前進程最希望從此node中分配到內存。
- 判斷一個node是否平衡的條件是：此node的ZONE_NORMAL和ZONE_DMA兩個區的空閑頁框數量 > 此node的ZONE_NORMAL和ZONE_DMA兩個區的平均min閥值。如果不平衡，則加入到pgdat->pfmemalloc_wait等待隊列中，如果平衡，則直接返回，並由當前進程自己進行直接內存回收。
- 如果當前進程分配內存時使用的標志沒有__GFP_FS，則加入pgdat->pfmemalloc_wait中會有一個超時限制，為1s。並且加入后的狀態是TASK_INTERRUPTABLE。
- 其他情況的進程加入到pgdat->pfmemalloc_wait中沒有超時限制，並且狀態是TASK_KILLABLE。
如果進程加入到了node的pgdat->pfmemalloc_wait等待隊列中。在此node的kswapd進行內存回收后，會通過再次判斷此node是否平衡來喚醒這些進程，如果node平衡，則喚醒這些進程，否則不喚醒。實際上，不喚醒也說明了node沒有平衡，kswapd還是會繼續進行內存回收，最后kswapd實在沒辦法讓node達到平衡水平下，會在kswapd睡眠前，將這些進程全部進行喚醒。
zone的保留內存
之前很多地方說明到，判斷一個zone是否達到閥值，主要通過zone_watermark_ok()函數實現的，而在此函數中，又以 zone當前空閑內存 >= zone閥值(min/low/high) + 1 << order + 保留內存 這個公式進行判斷的，而對於zone閥值和1<<order都很好理解，這里主要說說最后的那個保留內存。我們知道，如果打算從ZONE_HIGHMEM進行內存分配時，使用的zonelist是ZONE_HIGHMEM -> ZONE_NORMAL -> ZONE_DMA，當ZONE_HIGHMEM沒有足夠內存時，就會去ZONE_NORMAL和ZONE_DMA進行分配，這樣會造成一種情況，有可能ZONE_NORMAL和ZONE_DMA的內存都被本應該從ZONE_HIGHMEM分配的內存占完了，特定需要從ZONE_NORMAL和ZONE_DMA分配的內存則無法進行分配，所以內核設計了一個功能，就是讓其他ZONE內存不足時，可以在本ZONE進行內存分配，但是必須保留一些頁框出來，不能讓你所有都用完，而應該從本ZONE進行分配的時候則沒辦法獲取頁框，這個值就保存在struct zone中：
struct zone { ...... long lowmem_reserve[MAX_NR_ZONES]; ...... }
注意是以數組保存這個必須保留的頁框數量的，而數組長度是node中zone的數量，為什么要這樣組織，其實很好理解，對於對不同的zone進行的內存分配，如果因為目標zone的內存不足導致從本zone進行分配時，會因為目標zone的不同而保留的頁框數量不同，比如說，一次內存分配本來打算在ZONE_HIGHMEM進行分配，然后內存不足，最后到了ZONE_DMA進行分配，這時候ZONE_DMA使用的保留內存數量就是lowmem_reserve[ZONE_HIGHMEM]；而如果一次內存分配是打算在ZONE_NORMAL進行分配，因為內存不足導致到了ZONE_DMA進行分配，這時候ZONE_DMA使用的保留內存數量就是lowmem_reserve[ZONE_NORMAL]。這樣，對於這兩次內存分配過程中，當對ZONE_DMA調用zone_watermark_ok()進行閥值判斷能否從ZONE_DMA進行內存分配時，公式就會變為 zone當前空閑內存 >= zone閥值(min/low/high) + 1 << order + lowmem_reserve[ZONE_HIGHMEM] 和 zone當前空閑內存 >= zone閥值(min/low/high) + 1 << order + lowmem_reserve[ZONE_NORMAL]。這樣就可能會因為lowmem_reserve[ZONE_HIGHMEM]和lowmem_reserve[ZONE_NORMAL]的不同，導致一種能夠順利從ZONE_DMA分配到內存，另一種不能夠。而對於本來就打算從本zone進行內存分配時，比如本來就打算從ZONE_DMA進行內存分配，就會使用lowmem_reserve[ZONE_DMA]，而由於zone本來就是ZONE_DMA，所以ZONE_DMA的lowmem_reserve[ZONE_DMA]為0，也就是，當打算從ZONE_DMA進行內存分配時，會使用zone_watermark_ok()判斷ZONE_DMA是否達到閥值，而判斷公式中的保留內存lowmem_reverve[ZONE_DMA]是為0的。同理，當本來就打算從ZONE_NORMAL進行內存分配，並通過zone_watermark_ok()對ZONE_NORMAL進行閥值判斷時，會使用ZONE_NORMAL區的lowmem_reserve[ZONE_NORAML]，這個值也是0。對於ZONE_NORMAL區而言，它的lowmem_reserve[ZONE_DMA]和lowmem_reserve[ZONE_NORMAL]為0，因為需要從ZONE_DMA進行內存分配時，即使內存不足也不會到ZONE_NORMAL進行分配，而由於自己又是ZONE_NORMAL區，所有這兩個數為0；而對於ZONE_HIGHMEM，它的lowmem_reserve[]中所有值都為0，它不必為其他zone限制保留內存，因為其他zone當內存不足時不會到ZONE_HIGHMEM中進行嘗試分配內存。
可以通過cat /proc/zoneinfo查看這個數組中的值為多少：
這個是我的ZONE_DMA的區的參數，可以看到，對應ZONE_DMA就是為0，然后ZONE_NORMAL和ZONE_HIGHMEM都為1854，最后一個是虛擬的zone，叫ZONE_MOVABLE。
對於zone保留內存的多少，可以通過/proc/sys/vm/lowmem_reserve_ratio進行修改。具體可見內核文檔Documentation/sysctl/vm.txt，我的系統默認的lowmem_reserve_ratio如下：
這個256和32代表的是1/256和1/32。而第一個256用於代表DMA區的，第二個256代表NORMAL區的，第三個32代表HIGHMEM區的，計算公式是：
ZONE_DMA對於ZONE_NORMAL分配需要保留的內存：
zone_dma->lowmem_reserve[ZONE_NORMAL] = zone_normal.managed / lowmem_reserve_ratio[ZONE_DMA]
ZONE_DMA對於ZONE_HIGHMEM分配需要保留的內存：
zone_dma->lowmem_reserve[ZONE_HIGHMEM] = zone_highmem.managed / lowmem_reserve_ratio[ZONE_DMA]
drop_caches
在/proc/sys/vm/目錄下有個drop_caches文件，可以通過將1,2,3寫入此文件達到內存回收的效果，這三個值會達到不同的效果，效果如下：
- echo 1 > /proc/sys/vm/drop_caches：對干凈的pagecache進行內存回收
- echo 2 > /proc/sys/vm/drop_caches：對空閑的slab進行內存回收
- echo 3 > /proc/sys/vm/drop_caches：對干凈的pagecache和slab進行內存回收
注意只會對干凈的pagecache和空閑的slab進行回收。干凈的pagecache就是頁中的數據與磁盤對應文件一致，沒有被修改過的頁，對於臟的pagecache，是不會進行回收的。而空閑的slab指的就是沒有被分配給內核模塊使用的slab。
先看看/proc/meminfo文件：
主要注意Buffers、Cached、Slab、Shmem這四行。
再看看free -k命令：
我們主要關注shared和buff/cache這兩列。
- shared：記錄的是當前系統中共享內存使用的內存數量，對應meminfo的Shmem行。
- buff/cache：記錄的是當前系統中buffers、cached、slab總共使用的內存數量。對應於meminfo中的Buffers + Cached + Slab。
然后我們通過free -k看看當前系統在使用echo 3 > /proc/sys/vm/drop_caches清空了pagecache和slab之后的情況：
這里為什么buff/cache在echo 3 > /proc/sys/vm/drop_caches后沒有被清0，因為之前也說了，drop_caches只回收空閑的pagecache和空閑的slab。
之后使用shmem創建一個100M的shmem共享內存，再通過echo 3 > /proc/sys/vm/drop_caches清空pagecache和slab之后的情況：
很明顯看出來，兩次的shared相差102400，兩次的buff/cache相差102364。也就是這段shmem共享內存沒有被drop_caches回收，實際上，mmap共享內存也是與shmem相同的情況，也就是說，共享內存是不會被drop_caches進行回收的。實際總體上drop_caches不會回收以下內存：
- 正在使用的slab，一些空閑的slab會被drop_caches回收
- 匿名mmap共享內存和文件映射mmap共享內存使用的頁，不會被drop_caches回收，但是在內存不足時會被內存回收換出
- shmem共享內存使用的頁，不會被drop_caches回收，但是在內存不足時會被內存回收換出
- tmpfs使用的頁
- 被mlock鎖在內存中的pagecache
- 臟的pagecache
有些人會很好奇，為什么shmem和mmap共享內存使用的頁都算成了pagecache，而在linux內存源碼分析 - 內存回收(lru鏈表)中明確說明了，shmem和匿名mmap共享內存使用的頁會加到匿名頁lru鏈表中的，在匿名頁lru鏈表中的頁有個特點，在要被換出時，會加入到swapcache中，然后再進行換出。實際上，這兩種類型的共享內存，在創建時，系統會為它們分配一個沒有映射到磁盤上的inode結點，當然也會有inode對應pagecache，但是它們會設置PG_swapbacked，並加入到匿名頁lru鏈表中，當對它們進行換出時，它們會加入到swapcache中進行換出。也就是在沒有被換出時，這些沒有指定磁盤文件的共享內存，是有屬於自己的inode和pagecache的，所以系統也將它們算作了pagecache。而對於文件映射mmap共享內存，它本來就有對應的文件inode和pagecache，所以算到pagecache中也理所應當了。
以上說了為什么shmem和匿名mmap被系統算作pagecache，這里再說說為什么drop_caches沒有對它們這種pagecache進行釋放。首先，drop_caches的實現原理時，遍歷系統中所有掛載了的文件系統的超級塊struct super_block，對每個文件系統的超級塊中的每個文件的inode進行遍歷，然后再對每個文件inode中的所有page進行遍歷，然后將能夠回收的回收掉，實際上，嚴格地判斷pagecache能否回收的條件如下：
- 標記了PG_dirty的臟pagecache不能回收
- 有進程頁表項映射的pagecache不能回收
- 被mlock鎖在內存中的pagecache不能回收
- 標記了PG_writeback的正在回寫的pagecache不能回收
- 沒有buffer_head並且page->_count不等於2的pagecache不能進行回收
- 有buffer_head並且page->_count不等於3的pagecache不能進行回收
到這里，實際上已經很清晰了，對於只有write、read進行讀寫的文件，只要它是干凈並且沒有被mlock鎖在內存中，基本上都是能夠回收的，因為write、read系統調用不會讓進程頁表映射此pagecache。而相反，mmap和shmem都會讓進程頁表映射到pagecache，這樣當某個pagecache被使用了mmap或shmem的進程映射時，這個pagecache就不能夠進行回收了。而shmem相對於mmap還有所不同，mmap在進程退出時，會取消映射，這時候這些被mmap取消映射的pagecache是可以進行回收的，但是當一個進程使用shmem進行共享內存時，然后進程退出，shmem共享內存使用的pagecache也還是不能夠被drop_caches進行回收，原因是shmem共享內存使用的pagecache的page->_count為4，不為上面的2或者3的情況，具體shmem共享內存的pagecache被哪個模塊引用了，還待排查。總的來說，mmap使用的頁不能夠回收是因為有進程映射了此頁，shmem使用的頁不能夠回收是因為有其他模塊引用了此頁。
再說說tmpfs，tmpfs中的文件頁也是不能夠被drop_caches回收的，原因是tmpfs中的文件頁生來就是臟頁，而又因為它們在磁盤上沒有對應的具體磁盤文件，所以tmpfs中的文件頁不會被回寫到磁盤，又因為生來是臟頁，所以tmpfs的文件頁在內存充足的情況下，它的整個生命周期都為臟頁，所以不會被drop_caches回收。
需要注意，上面所說的所有情況，都表示是drop_caches不能進行回收，但是不代表這些頁是不能進行回收的，在內存不足時導致的內存回收流程，就會將shmem、mmap、tmpfs中的頁進行換出到swap分區或者對應磁盤文件中。
kmalloc從slab/slub或者從buddy system分配的分界線
當kmalloc分配的內存大小超過一定值時, 就會從buddy system去分配, 而不是從slab中獲取.
當size > KMALLOC_MAX_CACHE_SIZE時, 從buddy system分配, 否則從slab中分配.
而KMALLOC_MAX_CACHE_SIZE在slab和slub中的定義不一樣, 不過都是在include/linux/slab.h中
slub:
KMALLOC_MAX_CACHE_SIZE為1UL << (PAGE_SHIFT + 1), 如果page大小為4K(PAGE_SHIFT則為12), 那么KMALLOC_MAX_CACHE_SIZE為8K, 也就是當kmalloc分配的大小超過8K時, 就會從buddy system中分配.
slab:
KMALLOC_MAX_CACHE_SIZE為1UL << ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? (MAX_ORDER + PAGE_SHIFT - 1) : 25), 默認情況下, MAX_ORDER為11, 那么MAX_ORDER + PAGE_SHIFT - 1為22, 那么KMALLOC_MAX_CACHE_SIZE為4M, 也就是說, 當kmalloc分配大小超過4M時, slab才會從buddy system分配, 但是很顯然這里是無法從buddy system分配的. 因為MAX_ORDER為11時, buddy system最大也就組織了4M的連續空間. 根據kernel的注釋, slab模式下, KMALLOC_MAX_CACHE_SIZE最大能夠達到2^25(32MB).