[内核内存] [arm64] 深入解析zone区域水线(watermark)与保留内存(lowmem_reserve)的协同机制

1. 内存管理基础：zone区域与水线机制

在arm64架构的Linux内核中，物理内存被划分为多个zone区域，每个zone都有自己独立的内存水线（watermark）设置。这就像城市供水系统中的水位警戒线，当水位低于某个阈值时就会触发相应的应急机制。

内存zone区域通常包括DMA、DMA32和NORMAL等类型，每个zone都维护着三个关键水线值：

• WMARK_MIN（最低水线）：空闲内存低于此值，系统将进入紧急状态，直接同步回收内存
• WMARK_LOW（低水线）：空闲内存低于此值，系统会异步唤醒kswapd进程进行内存回收
• WMARK_HIGH（高水线）：内存回收的目标水位，达到此值后kswapd会停止工作

这三个水线值不是固定不变的，它们会根据系统总内存大小动态计算。举个例子，在一个16GB内存的服务器上，DMA32 zone的典型水线值可能是：

• WMARK_MIN = 2500页（约10MB）
• WMARK_LOW = 3100页（约12.4MB）
• WMARK_HIGH = 3700页（约14.8MB）

当系统进行内存分配时，buddy分配器会检查当前zone的空闲页数：

// 内核中的水线检查代码示例 static bool __zone_watermark_ok(struct zone *z, unsigned int order, unsigned long mark) { long free_pages = zone_page_state(z, NR_FREE_PAGES); free_pages -= (1 << order) - 1; return free_pages > mark + z->lowmem_reserve[classzone_idx]; }

2. watermark的初始化与动态调整

2.1 关键参数min_free_kbytes

min_free_kbytes是控制整个系统保留内存的最小值，它直接影响所有zone的WMARK_MIN计算。这个值的确定很有讲究：

1. 默认计算公式：min_free_kbytes = sqrt(lowmem_kbytes * 16)
2. 取值范围限制在128KB到65536KB之间
3. 实际项目中建议不低于1024KB，否则系统在高负载时容易死锁

在系统启动时，内核通过init_per_zone_wmark_min()函数计算这个值：

lowmem_kbytes = nr_free_buffer_pages() * (PAGE_SIZE >> 10); new_min_free_kbytes = int_sqrt(lowmem_kbytes * 16);

2.2 水线的动态计算

每个zone的水线值通过setup_per_zone_wmarks()函数计算，主要逻辑是：

1. 非HIGHMEM zone的WMARK_MIN按内存比例分配min_free_kbytes
2. WMARK_LOW = WMARK_MIN + (zone内存 × watermark_scale_factor / 10000)
3. WMARK_HIGH = WMARK_MIN + 2 × (zone内存 × watermark_scale_factor / 10000)

这里有个有趣的细节：watermark_scale_factor是内核4.6引入的新参数，默认值10表示0.1%的内存占比。它让水线设置能更好地适应大内存机器。

2.3 用户态调节接口

系统提供了两个重要的调节接口：

# 查看当前设置 cat /proc/sys/vm/min_free_kbytes cat /proc/sys/vm/watermark_scale_factor # 动态调整（立即生效） echo 8192 > /proc/sys/vm/min_free_kbytes echo 500 > /proc/sys/vm/watermark_scale_factor

在云原生环境中，我经常需要根据工作负载特性调整这些参数。比如对于内存密集型应用，适当提高watermark_scale_factor可以减少内存回收带来的延迟波动。

3. lowmem_reserve机制解析

3.1 保留内存的作用

lowmem_reserve是zone为高阶zone预留的内存保护区，防止高阶zone过度侵占低阶zone的内存。这就像城市中的应急物资储备，平时不能动用，只在特定情况下使用。

在典型的arm64系统中，我们可以通过以下命令查看设置：

cat /proc/sys/vm/lowmem_reserve_ratio # 典型输出：256 256 32

这三个比值分别对应DMA、DMA32和NORMAL zone的保留比例。计算方式很巧妙：

• DMA要为DMA32保留：DMA32内存大小/256
• DMA要为NORMAL保留：(DMA32+NORMAL)内存大小/256
• DMA32要为NORMAL保留：NORMAL内存大小/256

3.2 内核实现细节

setup_per_zone_lowmem_reserve()函数负责计算各zone的保留内存：

for (j = 0; j < MAX_NR_ZONES; j++) { while (idx) { lower_zone->lowmem_reserve[j] = managed_pages / sysctl_lowmem_reserve_ratio[idx]; managed_pages += lower_zone->managed_pages; } }

实际项目中遇到过一个问题：某嵌入式设备频繁出现DMA分配失败，检查发现是lowmem_reserve_ratio设置过大（默认256），导致DMA zone实际可用内存太少。通过调整为128解决了问题。

4. 水线与保留内存的协同工作

4.1 内存分配时的联合判断

当内核尝试分配内存时，会通过zone_watermark_ok()函数进行双重检查：

1. 检查空闲内存是否高于（水线 + 对应zone的保留内存）
2. 检查伙伴系统是否有足够的连续页块

bool __zone_watermark_ok(struct zone *z, unsigned int order, unsigned long mark) { if (free_pages <= min + z->lowmem_reserve[classzone_idx]) return false; for (o = order; o < MAX_ORDER; o++) { if (!list_empty(&area->free_list[mt])) return true; } return false; }

4.2 实际应用场景分析

场景一：混合部署环境在同时运行在线服务和批处理任务的服务器上，合理设置watermark_scale_factor可以防止批处理任务占用过多内存影响在线服务。我通常会将这个值设为200-300（即2%-3%），既能保证内存利用率，又能控制回收延迟。

场景二：内存碎片问题当系统运行时间较长出现内存碎片时，可以临时提高min_free_kbytes，迫使内核进行更积极的内存整理。这比直接触发OOM要温和得多。

5. 性能调优实践经验

5.1 监控关键指标

建议监控以下/proc信息：

watch -n 1 'cat /proc/zoneinfo | grep -A5 Node' # 关注pages free和protection值 cat /proc/vmstat | grep allocstall # 监控直接回收次数

5.2 调优案例分享

在某次性能优化中，发现一个Java应用频繁触发直接内存回收（allocstall计数高）。通过分析发现：

1. watermark_scale_factor使用默认值10（0.1%）
2. 系统有128GB内存，实际水线区间只有约130MB
3. 调整为300后，回收频率明显降低，应用延迟改善15%

调整方法：

echo 300 > /proc/sys/vm/watermark_scale_factor

记得在/etc/sysctl.conf中持久化配置：

vm.watermark_scale_factor = 300

arm64架构下的内存管理需要特别关注大页支持，有时还需要配合调整/proc/sys/vm/nr_hugepages。在实际项目中，我通常会先用stress-ng工具模拟内存压力，观察系统行为后再确定最佳参数。