内存管理-52-memory overcommit-1-文档翻译

一、overcommit-accounting.rst

 注: 翻译自 msm-5.4/Documentation/vm/overcommit-accounting.rst

======================
超额分配记账
=====================

Linux 内核支持以下超额分配处理模式：

0: 启发式超额分配处理。拒绝明显的地址空间超额分配。适用于典型系统。它确保严重的内存分配失败，同时允许超额分配以减少交换空间的使用。在此模式下，root 用户被允许分配略多的内存。这是默认模式。

1: 总是超额分配。这适用于某些科学应用。一个典型的例子是使用稀疏数组(sparse arrays)的代码，并且几乎完全依赖于由零页组成的虚拟内存。

2: 不要过度分配内存。系统分配的总地址空间不得超过交换空间加上一个可配置的物理内存大小(默认值为 50%)。根据您使用的内存大小，在大多数情况下，这意味着进程在访问页面时不会被kill，但会根据情况收到内存分配错误。
这对于希望确保其内存分配在未来可用而无需初始化每个页面的应用程序非常有用。//TODO: 意思是这种模式下分配虚拟内存时就直接给分配物理内存了吗？#####

超额分配策略通过 sysctl ``vm.overcommit_memory`` 设置。

超额分配量可以通过 ``vm.overcommit_ratio``（百分比）或 ``vm.overcommit_kbytes``（绝对值）设置。

当前的超额分配限制和已分配量分别在 ``/proc/meminfo`` 中以 CommitLimit 和 Committed_AS 的形式查看。

注意事项
=======

C 语言的栈增长会隐式地进行内存重映射 (mremap)。如果您需要绝对保证并且接近栈的极限，则必须将栈映射为所需最大大小。对于典型的栈使用情况，这无关紧要，但如果您非常在意，则这是一个特殊情况。

在模式 2 中，MAP_NORESERVE 标志将被忽略。

工作原理
============

超额分配基于以下规则

对于基于文件的映射
| SHARED or READ-only - 0 成本（文件即映射，而非交换空间）
| PRIVATE WRITABLE - 每个实例的映射大小

对于匿名映射或 ``/dev/zero`` 映射
| SHARED - 映射大小
| PRIVATE READ-only - 0 成本（但用途不大）
| PRIVATE WRITABLE - 每个实例的映射大小

附加统计
| mmap 创建的可写副本页面
| 从同一内存池提取的 shmfs 内存

状态
======
* 我们统计 mmap 内存映射
* 我们统计 mprotect 在提交中的更改
* 我们统计 mremap 大小的更改
* 我们统计 brk
* 我们统计 munmap
* 我们在 /proc 中报告提交状态
* 统计并检查 fork
* 审查 exec 中的堆栈处理/构建
* SHMfs 统计
* 实现实际的限制强制执行

 

待办事项
=====
* 统计 ptrace 页数（这很困难）

二、proc.txt 中overcommit的部分

注: 翻译自 msm-5.4/Documentation/filesystems/proc.txt

> cat /proc/meminfo

(1) CommitLimit：基于超额分配比率('vm.overcommit_ratio')，这限制当前系统上可分配的虚拟内存总量。仅当启用严格超额分配统计('vm.overcommit_memory' 中的模式 2)时，才会遵守此限制。

CommitLimit 的计算公式如下：

CommitLimit = ([total RAM pages] - [total huge TLB pages]) * overcommit_ratio / 100 + [total swap pages]

例如，在一个具有 1GB 物理 RAM 和 7GB 交换空间，且 `vm.overcommit_ratio` 为 30 的系统中，CommitLimit 为 7.3GB。

更多详情，请参阅 vm/overcommit-accounting.rst 中的内存超额分配文档。

(2) Committed_AS：系统当前已提交的虚拟内存分配量。已提交内存是指所有进程已分配内存的总和，即使这些内存尚未被进程“使用”。例如，一个进程使用 malloc() 分配了 1GB 内存，但实际只使用了其中的 300MB(也即只分配了300M的物理内存)，此值仍会显示其使用了 1GB 内存。这 1GB 内存已被VM“提交”，分配内存的应用程序可以随时使用。如果系统启用了严格的超额分配(在 'vm.overcommit_memory' 中设置为 mode 2)，则不允许分配超过 CommitLimit（如上所述）的内存。这在需要确保进程在成功分配内存后不会因内存不足而失败时非常有用。