Overcommit_memory =0 中的启发式算法是什么意思？

Question

我通读了 man proc 的文档。当谈到 overcommit_memory 时，overcommit_memory=0 中的启发式不太好理解。启发式实际上是什么意思？

“不检查使用 MAP_NORESERVE 调用 mmap(2)”是否意味着内核只分配虚拟内存而不知道交换空间的存在？

该文件包含内核虚拟内存记帐模式。值是：

                     0：启发式过量使用（这是默认设置）
                     1：总是过量使用，从不检查
                     2：始终检查，永远不要过度使用

              模式0下，不检查mmap(2)和MAP_NORESERVE的调用，默认检查很弱，导致风险
              获得一个进程“OOM 杀死”。

除了前面的问题，虚拟地址空间耗尽是否会导致 OOM，而不管剩余的物理内存是否足够。

谢谢。

Answer 1

该overcommit_memory设置在内存管理子系统中的三个位置被考虑在内。

1. 主要的是__vm_enough_memoryin mm/util.c，它决定是否有足够的内存来允许内存分配继续进行（请注意，这是一个不一定要调用的实用程序函数）。如果overcommit_memory是 1，这个函数总是成功的。如果是 2，则检查实际可用内存。如果为 0，则使用您提到的著名启发式；其进行如下：

   • 计算空闲页数
   • 添加文件支持页面的数量（这些可以恢复）
   • 删除用于共享内存的页面
   • 添加交换页面
   • 添加可回收页面
   • 保留页面的帐户
   • 为 root 留一些内存（如果分配不是由cap_sys_admin进程完成的）

   结果总数用作内存分配的阈值。

2. mmap还检查设置：MAP_NORESERVE如果允许过量使用（模式 0 和 1），则遵守，并导致分配没有后备交换 ( VM_NORESERVE)。在这种特殊情况下，模式 0 实际上等效于模式 1；这就是“不检查mmap(2)with 的调用MAP_NORESERVE”所指的：这意味着MAP_NORESERVE mmap调用将始终成功，并且过度分配将导致 OOM 杀手在事后介入，或者在尝试写入时发生段冲突。

3. shmem具有与 类似的行为mmap。

地址空间用完应该会导致分配失败，而不是 OOM-kills，因为分配实际上无法继续。