【转载】内存基本概念-watermark&lowmem_reserve
概述
当系统内存短缺的情况下仍去申请内存，可能会触发系统对内存的回收，那什么时候应该进行回收，回收到什么标准又可以停止回收，参考依据是什么？即本文将介绍的watermark(内存水位线)，当检查watermark时又不单单是判断watermark，还会牵扯到lowmem_reserve[]，关于lowmem_reserve本文会一并介绍。
说明：内核版本 5.9-rc2
watermark的概念
系统中每个NUMA node的每个struct zone中都定义着一个_watermark[NRWMARK]数组，其中存放着该zone的min、low和high三种内存水位线。简单来说，它们是衡量当前系统剩余内存是否充足的一个标尺。当zone中的剩余内存高于high时说明剩余内存充足，低于low但高于min时说明内存短缺但是仍可分配内存，若低于min则说明剩余内存极度短缺将停止分配(GFP_ATOMIC类型的分配例外)并全力回收。
下图展示了min、low、high和内存回收的关系：
看图说话：
开始随着横轴time的增长，纵轴剩余内存total size由于内存分配急剧下降，当total size低于low的时候，会唤醒kswapd内核线程进行异步回收(所谓异步回收，就是此时仍可以分配内存，内存回收通过kswapd内核线程在后台同时进行)；若回收的速度小于分配的速度，total size会降至min水位线以下，此时会触发同步回收，即在__alloc_pages_slowpath函数中阻塞分配内存并尝试直接内存回收(reclaim)、内存压缩(compact)、更甚者OOM Killer强制回收；直到tatol size大于high水位线，回收才会停止。整体呈现为一个"V"字形状。
简单总结：
high：高于high时，kswapd会睡眠。
low：低于low时，kswapd会被唤醒。
min：低于min时，说明在low和min之间kswapd的回收的速度低于分配，因此阻塞分配，并通过各种形式回收内存。
补充：细心的话会发现，当内存低于min时还会下降一小段，说明仍然可以分配内存。但仅仅限于内核中的一些紧急的分配或是带有GFP_ATOMIC标志的分配请求，会放宽对watermark的检查，放宽多少，具体参看后面__zone_watermark_ok()函数的实现。
大小关系：
high：low：min == 6：5：4
(这是系统启动后默认的比例，用户可以通过procfs下的watermark_scale_factor进行调节)
追根溯源watermark：
procfs下面有个min_free_kbytes的接口，它对应kernel中的一个同名全局变量min_free_kbytes，表示上文提到的内存水位线min的大小。用户可以通过procfs下的/proc/sys/vm/min_free_kbytes节点去调节它。但是它的值的范围不得大于256MB，不得小于128KB。若用户不去调节它，在系统启动时会为它计算一个初值，并根据这个值扩大1.25倍和1.5倍分别作为low和high的值。
这些工作都是在init_per_zone_wmark_min()函数中实现，不贴代码了，直接看函数内容的提炼，如图：
(图中说明了全局变量min_free_kbytes的计算方法，以及如何根据min_free_kbytes为各个zone设置它们的min、low和high。)
检查watermark
kernel中检查watermark的函数有两个：zone_watermark_fast和__zone_watermark_ok，它们会在每次rmqueue分配内存前被调用用来检查watermark。
其中zone_watermark_fast()是_zone_watermark_ok()的扩展版本，增加了对order 0分配的快速检查。我们详细看下基础版本__zone_watermark_ok :
bool __zone_watermark_ok(struct zone *z, unsigned int order, unsigned long mark,
int highest_zoneidx, unsigned int alloc_flags,
long free_pages)
{
long min = mark;
/*将当前zone中的free pages刨去不可用于分配的pages*/
free_pages -= __zone_watermark_unusable_free(z, order, alloc_flags);
/*上文提到的，若是紧急分配，watermark的标准将被放宽*/
if (alloc_flags & ALLOC_HIGH)
min -= min / 2;
if (unlikely(alloc_harder)) {
if (alloc_flags & ALLOC_OOM)
min -= min / 2;
else
min -= min / 4;
}
/*1.引入lowmem_reserve的概念;2.这里的min实际上可能是min low high
注意：对水线的检查实际还会在watermark的基础上加上lowmem_reserve的
值，若当前zone是preferred zone，那么lowmem_reserve[x]=0。
*/
if (free_pages <= min + z->lowmem_reserve[highest_zoneidx])
return false;
/* 如果请求是order-0，那么一定可以得到order-0的page，返回true */
if (!order)
return true;
/*若不是order-0的请求，则检查free_area[]中是否有存在大于等于目标order的page*/
for (o = order; o < MAX_ORDER; o++) {
struct free_area *area = &z->free_area[o];
int mt;
if (!area->nr_free)
continue;
for (mt = 0; mt < MIGRATE_PCPTYPES; mt++) {
if (!free_area_empty(area, mt))
return true;
}
}
return false;
}
结论：watermark的检查不仅仅是对watermark的检查，还要在watermark的基础上加上lowmemreserve的值(下文将会介绍原因)，后续再判断free_area中是否存在可以满足目标order分配需求的pages，全都都符合才算watermark ok～
lowmem_reserve的概念：
好了，是时候了解一下什么是lowmem_reserve了。
kernel在分配内存时，可能会涉及到多个zone，分配会尝试从zonelist第一个zone分配，如果失败就会尝试下一个低级的zone（这里的低级仅仅指zone内存的位置，实际上低地址zone是更稀缺的资源）。
考虑这样一种场景应用进程通过内存映射申请Highmem 并且加mlock分配，如果此时HIGH zone无法满足分配，则会尝试从Normal进行分配。问题来了，应用进程在从HIHG“降”到Normal区的分配请求有可能会耗尽Normal区的内存，而且由于mlock又无法回收，最终的结果就是Normal区无内存-在i386这样的架构上内核能够正常访问的线性区正是Normal区，这就导致kernel可能无法正常工作，然而HIGH zone却可能有足量的可回收内存。
针对这个情形，当Normal zone在碰到来自HIGH的分配请求时，可以通过lowmem_reserve声明：可以使用我的内存，但是必须要保留lowmem_reserve[NORMAL]给我自己使用。
同样当从Normal失败后，会尝试从zonelist中的DMA申请分配，通过lowmem_reserve[DMA]，限制来自HIGHMEM和Normal的分配请求。
保留内存的初始化
有了上面的铺垫我们看一下各个区的lowmem_reseve[]是如何配置的，各个区究竟保留了多少内存。
【1】内核定义了一个long lowmem_reserve[MAX_NR_ZONES]数组来表示各个区的保留内存。这个数组的大小MAX_NR_ZONES与内核配置有关系，例如内核使能了CONFIG_ZONE_DMA、CONFIG_ZONE_DMA32、则MAX_NR_ZONES值为4，他们是：
enum zone_type {
ZONE_DMA, /* 0 */
ZONE_DMA32,
ZONE_NORMAL,
ZONE_MOVABLE,
__MAX_NR_ZONES /* 3 */
};
【2】那各个lowmem_reserve[MAX_NR_ZONES]是如何计算的呢？
我们来看看这个数组的初始化流程，它是由setup_per_zone_lowmem_reserve(void)函数来完成的。
static void setup_per_zone_lowmem_reserve(void)
{
struct pglist_data *pgdat;
enum zone_type j, idx;
/* 遍历各个节点，我们考虑的UMA场景只有一个节点 */
for_each_online_pgdat(pgdat) {
/* 从DMA zone开始遍历，假设这里有ZONE_DMA，ZONE_DMA32，ZONE_NORMAL，ZONE_MOVABLE四个zone */
for (j = 0; j < MAX_NR_ZONES; j++) {
struct zone *zone = pgdat->node_zones + j;
unsigned long managed_pages = zone->managed_pages;
/*
* 当j=0时：zone[DMA].lowmem_reserve[DMA] = 0 (不进入while循环)
* 当j=1时：zone[DMA32].lowmem_reserve[DMA32] = 0
*/
zone->lowmem_reserve[j] = 0;
idx = j;
while (idx) {
struct zone *lower_zone;
idx--;
lower_zone = pgdat->node_zones + idx;
if (sysctl_lowmem_reserve_ratio[idx] < 1) {
sysctl_lowmem_reserve_ratio[idx] = 0;
lower_zone->lowmem_reserve[j] = 0;
} else {
/*
* 当j=1时实际计算为：
* zone[DMA].lowmem_reserve[DMA32] = zone[DMA32]->managed_pages / sysctl_lowmem_reserve_ratio[DMA]
* 当j=2时实际计算为：
* zone[DMA32].lowmem_reserve[NORMAL] = zone[NORMAL]->managed_pages / sysctl_lowmem_reserve_ratio[DMA32] ( idx=1)
* zone[DMA].lowmem_reserve[NORMAL] = (zone[NORMAL]->managed_pages + zone[DMA32]->managed_pages) / sysctl_lowmem_reserve_ratio[DMA] (idx=2)
* 当j=3时实际计算为：
* zone[NORMAL].lowmem_reserve[MOVE] = zone[MOVE]->managed_pages/sysctl_lowmem_reserve_ratio[NORMAL]
* zone[DMA32].lowmem_reserve[MOVE] = (zone[MOVE]->managed_pages + zone[NORMAL]->managed_pages) /
sysctl_lowmem_reserve_ratio[DMA32]
* zone[DMA].lowmem_reserve[MOVE] = (zone[MOVE]->managed_pages + zone[NORMAL]->managed_pages + zone[DMA32]->managed_pages)/
sysctl_lowmem_reserve_ratio[DMA]
*
*/
lower_zone->lowmem_reserve[j] =
managed_pages / sysctl_lowmem_reserve_ratio[idx];
}
/*
* 当j=2时，managed_pages = zone[NORMAL]->managed_pages + zone[DMA32]->managed_pages
*/
managed_pages += lower_zone->managed_pages;
}
}
}
/* update totalreserve_pages */
calculate_totalreserve_pages();
}
上面的代码涉及的变量和参数较多，比较容易晕。我们对其中一个迭代进行实例化后就容易理解了。有了上面的理论，我们来看看真实情况和我们的理解是否一致。
实例验证
内核使用proc文件系统为用户提供了查看内存区信息的接口，我们一一观察。
首先看一下我们这个案例系统中的zone分布情况：
/ # cat /proc/buddyinfo
Node 0, zone DMA 29 35 20 19 13 3 3 1 1 1 0
Node 0, zone DMA32 482 533 479 352 244 71 35 21 16 13 131
可以看到系统里面只有两个zone，即DMA和DMA32。
接下来我们看看系统里面各个zone的的各个位段的保留内存lowmem_reserve情况：
sh-4.3# cat /proc/zoneinfo | grep protection
protection: (0, 1979, 1979, 1979)
protection: (0, 0, 0, 0)
上面的两行分别是：zone[DMA]lowmem_reserve[]、zone[DMA32]lowmem_reserve[]，其元素对应为如下：
zone[DMA].lowmem_reserve[DMA]=0， zone[DMA].lowmem_reserve[DMA32]=1979 ， zone[DMA].lowmem_reserve[NORMAL]=1979， zone[DMA].lowmem_reserve[MOVE]=1979
zone[DMA32].lowmem_reserve[DMA]=0， zone[DMA32].lowmem_reserve[DMA32]=0， zone[DMA32].lowmem_reserve[NORMAL]=0， zone[DMA32].lowmem_reserve[MOVE]=0
另外，我们从之前源代码分析了解到lowmem_reserve[]的计算还依赖两个其他参数sysctl_lowmem_reserve_ratio[] 和 zone->managed_pages。我们通过proc接口来分别查看一下这两个参数：
sh-4.3# cat /proc/zoneinfo | grep managed
managed 3976
managed 506662
sh-4.3# cat /proc/sys/vm/lowmem_reserve_ratio
256 256 32
首先，系统总共有DMA和DMA32两个zone，所以上面的managed也只有两行，分别为zone[DMA].managed_pages=3976， zone[DMA32].managed_pages=506662，单位是page；
其次，lowmem_reserve_ratio是用于控制保留内存数量的系数，这个是可手工修改的参数，其定义如下：
int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES-1] = {
#ifdef CONFIG_ZONE_DMA
256,
#endif
#ifdef CONFIG_ZONE_DMA32
256,
#endif
#ifdef CONFIG_HIGHMEM
32,
#endif
32,
};
所以在咱们的用例中(内核只使能了CONFIG_ZONE_DMA，CONFIG_ZONE_DMA32，没有使能CONFIG_HIGHMEM)。所以lowmem_reserve_ratio[]系数的值为：
sysctl_lowmem_reserve_ratio[DMA]=256, sysctl_lowmem_reserve_ratio[DMA32]=256, sysctl_lowmem_reserve_ratio[NORMAL]=32。
所有的参数和算法已经准备完毕，下面我们就来手动实际验算一下。
先看看zone[DMA]保留内存的情况：
zone[DMA].lowmem_reserve[DMA] = 0
zone[DMA].lowmem_reserve[DMA32]= zone[DMA32].managed_pages / sysctl_lowmem_reserve_ratio[DMA]
= 506662 / 256 = 1979
zone[DMA].lowmem_reserve[NORMAL] = (zone[NORMAL]->managed_pages + zone[DMA32]->managed_pages) / sysctl_lowmem_reserve_ratio[DMA]
= (0 + 506662)/256= 1979
zone[DMA].lowmem_reserve[MOVE] = (zone[MOVE]->managed_pages + zone[NORMAL]->managed_pages + zone[DMA32]->managed_pages)/
sysctl_lowmem_reserve_ratio[DMA]
= (0 + 0 + 506662)/256 = 1979
上面的计算结果 (0,1979,1979,1979)与我们从proc接口看到的protection字段看到的一致。
再看看zone[DMA32]的保留内存情况
zone[DMA32].lowmem_reserve[DMA32] = 0
zone[DMA32].lowmem_reserve[NORMAL] = zone[NORMAL]->managed_pages / sysctl_lowmem_reserve_ratio[DMA32]
= 0/256 = 0
zone[DMA32].lowmem_reserve[MOVE] = (zone[MOVE]->managed_pages + zone[NORMAL]->managed_pages) /
sysctl_lowmem_reserve_ratio[DMA32]
= (0 + 0)/256 = 0
从上面的接口可以看到这些代码中的算法计算出来的实际值与proc接口读出来的值相符。
总结
这篇文章还是从实际遇到的问题引出的。之前在某个环境出现过Normal区内存量远高于水线时出现OOM的情况，最后查明原因就是因为保留内存太多导致。最终通过调整sysctl_lowmem_reserve_ratio参数进行规避。
