如何理解kswapd的低水位min_free_kbytes

这篇文章给大家介绍如何理解kswapd的低水位min_free_kbytes，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。先看官方解释：

This is used to force the Linux VM to keep a minimum number of kilobytes

free. The VM uses this number to compute a watermark[WMARK_MIN] value

for each lowmem zone in the system. Each lowmem zone gets a number of

reserved free pages based proportionally on its size.

Some minimal amount of memory is needed to satisfy PF_MEM开发云主机域名ALLOC

allocations; if you set this to lower than 1024KB, your system will

become subtly broken, and prone to deadlock under high loads.

Setting this too high will OOM your machine instantly.

解释已经很清楚了，主要有以下几个关键点：在系统初始化时会根据内存大小计算一个默认值，计算规则是：

min_free_kbytes = sqrt(lowmem_kbytes * 16) = 4 * sqrt(lowmem_kbytes)(注：lowmem_kbytes即可认为是系统内存大小）

另外，计算出来的值有最小最大限制，最小为128K，最大为64M。

可以看出，min_free_kbytes随着内存的增大不是线性增长，comments里提到了原因“because network

bandwidth does not increase linearly with machine

size”。随着内存的增大，没有必要也线性的预留出过多的内存，能保证紧急时刻的使用量便足矣。1)开发云主机域名 watermark[high] > watermark [low] > watermark[min]，各个zone各一套2)在系统空闲内存低于

watermark[low]时，开始启动内核线程kswapd进行内存回收（每个zone一个），直到该zone的空闲内存数量达到watermark[high]后停止回收。如果上层申请内存的速度太快，导致空闲内存降至watermark[min]后，内核就会进行direct

reclaim（直接回收），即直接在应用程序的进程上下文中进行回收，再用回收上来的空闲页满足内存申请，因此实际会阻塞应用程序，带来一定的响应延迟，而且可能会触发系统OOM。这是因为watermark[min]以下的内存属于系统的自留内存，用以满足特殊使用，所以不会给用户态的普通申请来用。3）三个watermark的计算方法：

watermark[min] =

min_free_kbytes换算为page单位即可，假设为min_free_pages。（因为是每个zone各有一套watermark参数，实际计算效果是根据各个zone大小所占内存总大小的比例，而算出来的per

zone min_free_pages）

watermark[low] = watermark[min] * 5 / 4

watermark[high] = watermark[min] * 3 / 2

所以中间的buffer量为 high – low = low – min = per_zone_min_free_pages *

1/4。因为min_free_kbytes = 4*

sqrt(lowmem_kbytes），也可以看出中间的buffer量也是跟内存的增长速度成开方关系。4）可以通过/proc/zoneinfo查看每个zone的watermark

例如：3.min_free_kbytes大小的影响

min_free_kbytes设的越大，watermark的线越高，同时三个线之间的buffer量也相应会增加。这意味着会较早的启动kswapd进行回收，且会回收上来较多的内存（直至watermark[high]才会停止），这会使得系统预留过多的空闲内存，从而在一定程度上降低了应用程序可使用的内存量。极端情况下设置min_free_kbytes接近内存大小时，留给应用程序的内存就会太少而可能会频繁地导致OOM的发生。

min_free_kbytes设的过小，则会导致系统预留内存过小。kswapd回收的过程中也会有少量的内存分配行为（会设上PF_MEMALLOC）标志，这个标志会允许kswapd使用预留内存；另外一种情况是被OOM选中杀死的进程在退出过程中，如果需要申请内存也可以使用预留部分。这两种情况下让他们使用预留内存可以避免系统进入deadlock状态。For some specialised workloads on highmem machines it is dangerous

for the kernel to allow process memory to be allocated from the “lowmem”

zone. This is because that memory could then be pinned via the mlock()

system call, or by unavailability of swapspace.

And on large highmem machines this lack of reclaimable lowmem memory can be fatal.

So the Linux page allocator has a mechanism which prevents allocations which


could


use highmem from using too much lowmem. This means that a certain

amount of lowmem is defended from the possibility of being captured into

pinned user memory.

The `lowmem_reserve_ratio’ tunable determines how aggressive the kernel is in defending these lower zones.

If you have a machine which uses highmem or ISA DMA and your

applications are using mlock(), or if you are running with no swap then

you probably should change the lowmem_reserve_ratio setting.1.作用

除了min_free_kbytes会在每个zone上预留一部分内存外，lowmem_reserve_ratio是在各个zone之间进行一定的防卫预留，主要是防止高端zone在没内存的情况下过度使用低端zone的内存资源。

例如现在常见的一个node的机器有三个zone:

DMA，DMA32和NORMAL。DMA和DMA32属于低端zone，内存也较小，如96G内存的机器两个zone总和才1G左右，NORMAL就相对属于高端内存（现在一般没有HIGH

zone），而且数量较大（>90G)。低端内存有一定的特殊作用比如发生DMA时只能分配DMA zone的低端内存，因此需要在

尽量可以使用高端内存时 而 不使用低端内存，同时防止高端内存分配不足的时候抢占稀有的低端内存。计算方法内核利用上述的protection数组计算每个zone的预留page量，计算出来也是数组形式，从/proc/zoneinfo里可以查看：在进行内存分配时，这些预留页数值和watermark相加来一起决定现在是满足分配请求，还是认为空闲内存量过低需要启动回收。

例如，如果一个normal区(index =

2)的页申请来试图分配DMA区的内存，且现在使用的判断标准是watermark[low]时，内核计算出 page_free =

1355，而watermark + protection[2] = 3 + 2004 = 2007 >

page_free，则认为空闲内存太少而不予以分配。如果分配请求本就来自DMA zone，则 protection[0] =

0会被使用，而满足分配申请。

zone[i] 的 protection[j] 计算规则如下：默认的 lowmem_reserve_ratio[i] 值是：从上面的计算规则可以看出，预留内存值是ratio的倒数关系，如果是256则代表 1/256，即为 0.39% 的高端zone内存大小。

如果想要预留更多页，应该设更小一点的值，最小值是1（1/1 -> 100%）。和min_free_kbytes（watermark）的配合示例

下面是一段某线上服务器（96G）内存申请失败时打印出的log：

1）从第一行log“order:1, mode:0x20”可以看出来是GFP_ATOMIC类型的申请，且order = 1(page = 2 )2）第一次内存申请尝试在__alloc_pages_nodemask()里，首先调用 get_page_from_freelist()

尝试第一次申请，使用的标志位是 ALLOC_WMARK_LOW|ALLOC_CPUSET，它会对每个zone都做

zone_watermark_ok()的检查，使用的就是传进的watermark[low]阈值。

在zone_watermark_ok()里会考虑z->lowmem_reserve[]，导致在normal上的申请不会落到低端zone。比如对于DMA32：

free pages = 380032KB = 95008 pages 所以就认为DMA32也不平不ok，同理更用不了DMA的内存。

而对于normal自己内存来说，free pages = 56552 KB = 14138

pages，也不用考虑lowmem_reserve(0)，但这时还会考虑申请order(1)，减去order 0的12544个page后只剩

14138 – 12544 = 1594，也小于 low / 2 = (48788KB=12197pages) / 2 = 6098

pages。

所以初次申请尝试失败，进入__alloc_pages_slowpath() 尝试进行更为积极一些的申请。3)第二次内存申请尝试

__alloc_pages_slowpath()首先是通过 gfp_to_alloc_flags()

修改alloc_pages，设上更为强硬的标志位。这块根据原来的GFP_ATOMIC会设上 ALLOC_WMARK_MIN |

ALLOC_HARDER | ALLOC_HIGH。但活动：慈云数据爆款香港服务器，CTG+CN2高速带宽、快速稳定、平均延迟10+ms 速度快，免备案，每月仅需19元！！ 点击查看注意的是不会设上 ALLOC_NO_WATERMARKS

标志位。这个标志位不再判断zone的水位限制，属于优先级最高的申请，可以动用所有的reserve内存，但条件是（!in_interrupt()

&& ((p->flags & PF_MEMALLOC) ||

unlikely(test_thread_flag(TIF_MEMDIE))))，即要求不能在中断上下文，且是正在进行回收（例如kswapd）或者正在退出的进程。

之后进入拿着新的alloc_pages重新进入get_page_from_pagelist() 尝试第二次申请，虽然有了

ALLOC_HARDER和ALLOC_HIGH，但是不幸的是在3个zone的zone_watermark_ok检查中还是都无法通过，例如对于DMA32：

free pages = 380032KB = 95008 pages

因为设上了ALLOC_HIGH 所以会将得到的watermark[min]减半，即min = min/2 = 800K / 2 = 400K = 100pages

而又因为设上了ALLOC_HARDER，会再将min砍去1/4，即min = 3 * min / 4 = 100 pages * 3 / 4 = 75 pages

即便如此，min(75 pages) + lowmem_reserve

normal

= 95015，仍大于free pages，仍认为无法分配内存，同理DMA也不不成功，而normal中 free pages里连续8K的页太少也无法满足分配

第二次失败后，由于没有ALLOC_NO_WATERMARK也不会进入__alloc_pages_high_priority 进行最高优先级的申请，同时由于是GFP_ATOMIC类型的分配不能阻塞回收或者进入OOM，因此就以申请失败告终。

遇到此种情况可以适当调高 min_free_kbytes 使kswapd较早启动回收，使系统一直留有较多的空闲内存，同时可以适度降低

lowmem_reserve_ratio（可选），使得内存不足的情况下（主要是normal

zone）可以借用DMA32/DMA的内存救急（注意不能也不能过低）。关于如何理解kswapd的低水开发云主机域名位min_free_kbytes就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

本文从转载，原作者保留一切权利，若侵权请联系删除。

《如何理解kswapd的低水位min_free_kbytes》来自互联网同行内容，若有侵权，请联系我们删除！