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

一、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 页数（这很困难）