我們講頁框分配器的時候講到了快速分配和慢速分配，其中夥伴算法是在快速分配里做的，忘記的小夥伴我們再看下：

static struct page *
get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
const struct alloc_context *ac)
{
for_next_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask)
{
if (!zone_watermark_fast(zone, order, mark, ac_classzone_idx(ac), alloc_flags))
{
ret = node_reclaim(zone->zone_pgdat, gfp_mask, order);
switch (ret) {
case NODE_RECLAIM_NOSCAN:
continue;
case NODE_RECLAIM_FULL:
continue;
default:
if (zone_watermark_ok(zone, order, mark, ac_classzone_idx(ac), alloc_flags))
goto try_this_zone;

continue;
}
}

try_this_zone: //本zone正常水位
page = rmqueue(ac->preferred_zoneref->zone, zone, order, gfp_mask, alloc_flags, ac->migratetype);
}

return ;
}

可以看到在進行夥伴算法分配前有個關於水位的判斷，今天我們就看下水位的概念。

簡單的說在使用分區頁面分配器中會將可以用的free pages與zone里的水位(watermark)進行比較。

水位初始化

int __meminit init_per_zone_wmark_min(void)
{
unsigned long lowmem_kbytes;
int new_min_free_kbytes;

//nr_free_buffer_pages是獲取ZONE_DMA和ZONE_NORMAL區中高於high水位的總頁數nr_free_buffer_pages = managed_pages - high_pages
lowmem_kbytes = nr_free_buffer_pages * (PAGE_SIZE >> 10);
new_min_free_kbytes = int_sqrt(lowmem_kbytes * 16);

if (new_min_free_kbytes > user_min_free_kbytes) {
min_free_kbytes = new_min_free_kbytes;
//min的值必須在128kib-65536kib之間
if (min_free_kbytes < 128)
min_free_kbytes = 128;
if (min_free_kbytes > 65536)
min_free_kbytes = 65536;
} else {
pr_warn("min_free_kbytes is not updated to %d because user defined value %d is preferred\n",
new_min_free_kbytes, user_min_free_kbytes);
}
//得到總的min後，就可以根據各個zone在總內存中的占比，通過do_div計算出他們各自的min值。
setup_per_zone_wmarks;
refresh_zone_stat_thresholds;
setup_per_zone_lowmem_reserve;

return 0;
}

nr_free_buffer_pages 是獲取ZONE_DMA和ZONE_NORMAL區中高於high水位的總頁數nr_free_buffer_pages = managed_pages - high_pages
min_free_kbytes 是總的min大小，min_free_kbytes = 4 * sqrt(lowmem_kbytes)
setup_per_zone_wmarks 根據總的min值，再加上各個zone在總內存中的占比，然後通過do_div就計算出他們各自的min值，進而計算出各個zone的水位大小。min,low,high的關係如下：low = min *125%;

high = min * 150%

min:low:high = 4:5:6
setup_per_zone_lowmem_reserve 當從Normal失敗後，會嘗試從DMA申請分配，通過lowmem_reserve[DMA]，限制來自Normal的分配請求。其值可以通過/proc/sys/vm/lowmem_reserve_ratio來修改。

從這張圖可以看出：

如果空閒頁數目min值，則該zone非常缺頁，頁面回收壓力很大，應用程式寫內存操作就會被阻塞，直接在應用程式的進程上下文中進行回收，即direct reclaim。
如果空閒頁數目小於low值，kswapd線程將被喚醒，並開始釋放回收頁面。
如果空閒頁面的值大於high值，則該zone的狀態很完美, kswapd線程將重新休眠。

安卓系統中對水位的調節

為了避免direct reclaim，我們需要空餘的內存大小一直保持在min值以上。但安卓這種大量用戶操作網絡接收的系統中，難免會遇到數據量突然增大，需要臨時申請大量的內存，此時有可能kswapd回收的內存速度小於內存分配的速度，即發生direct reclaim，從而阻塞應用嚴重影響性能。

我們知道在內存分配時，只有low和min之間的區域才是kswapd活動的區域。而linux中默認的low與min之間的值又比較小，所以就很容易造成direct reclaim的情況。

「extra_free_kbytes」:

源於此，安卓在linux水位的基礎上增加了extra_free_kbytes的變量，這個extra時額外加在low和min之間的，它在min不變的情況下，讓low值有所增大。

源碼如下：

static void __setup_per_zone_wmarks(void)
{
unsigned long pages_min = min_free_kbytes >> (PAGE_SHIFT - 10);
unsigned long pages_low = extra_free_kbytes >> (PAGE_SHIFT - 10);

......

for_each_zone(zone) {
......
do_div(min, lowmem_pages);
......
}

calculate_totalreserve_pages;
}

想要知道extra_free_kbytes的引入是否取得效果，可以通過/proc/vmstat中的pageoutrun和allocstall來看，兩者分別代表了kswapd和direct reclaim啟動的次數。

「watermark_scale_factor」:

內核總是在進步的，在linux內核4.6版本中，又誕生了一種新的調節水位的方式，即watermark_scale_factor係數，其默認值是10，對應內存占比10/10000=0.1%，可通過/proc/sys/vm/watermark_scale_factor設置，最大值是1000。舉個例子：當其被設為1000時，意味著min與low之間的差值，low與high之間的差值都將是內存大小的10%(1000/10000)。

前面講的extra_free_kbytes的方式只增大了min和low之間的差值，而watermark_scale_factor則同時增大了min和low，low和high之間的差值。

至此，頁框分配器中的快速分配方式已經結束，下一篇讓我們進入頁框分配器的慢速分配方式：__alloc_pages_slowpath，涉及到內存碎片的整理和內存回收。

Linux分區頁框分配器之水位

水位初始化

安卓系統中對水位的調節