0001 :Original: Documentation/mm/overcommit-accounting.rst
0002
0003 :翻译:
0004
0005 司延腾 Yanteng Si <siyanteng@loongson.cn>
0006
0007 :校译:
0008
0009
0010
0011 ==============
0012 超量使用审计
0013 ==============
0014
0015 Linux内核支持下列超量使用处理模式
0016
0017 0
0018 启发式超量使用处理。拒绝明显的地址空间超量使用。用于一个典型的系统。
0019 它确保严重的疯狂分配失败，同时允许超量使用以减少swap的使用。在这种模式下，
0020 允许root分配稍多的内存。这是默认的。
0021 1
0022 总是超量使用。适用于一些科学应用。经典的例子是使用稀疏数组的代码，只是依赖
0023 几乎完全由零页组成的虚拟内存
0024
0025 2
0026 不超量使用。系统提交的总地址空间不允许超过swap+一个可配置的物理RAM的数量
0027 （默认为50%）。根据你使用的数量，在大多数情况下，这意味着一个进程在访问页面时
0028 不会被杀死，但会在内存分配上收到相应的错误。
0029
0030 对于那些想保证他们的内存分配在未来可用而又不需要初始化每一个页面的应用程序来说
0031 是很有用的。
0032
0033 超量使用策略是通过sysctl `vm.overcommit_memory` 设置的。
0034
0035 可以通过 `vm.overcommit_ratio` （百分比）或 `vm.overcommit_kbytes` （绝对值）
0036 来设置超限数量。这些只有在 `vm.overcommit_memory` 被设置为2时才有效果。
0037
0038 在 ``/proc/meminfo`` 中可以分别以CommitLimit和Committed_AS的形式查看当前
0039 的超量使用和提交量。
0040
0041 陷阱
0042 ====
0043
0044 C语言的堆栈增长是一个隐含的mremap。如果你想得到绝对的保证，并在接近边缘的地方运行，
0045 你 **必须** 为你认为你需要的最大尺寸的堆栈进行mmap。对于典型的堆栈使用来说，这并
0046 不重要，但如果你真的非常关心的话，这就是一个值得关注的案例。
0047
0048
0049 在模式2中，MAP_NORESERVE标志被忽略。
0050
0051
0052 它是如何工作的
0053 ==============
0054
0055 超量使用是基于以下规则
0056
0057 对于文件映射
0058 | SHARED or READ-only - 0 cost (该文件是映射而不是交换)
0059 | PRIVATE WRITABLE - 每个实例的映射大小
0060
0061 对于匿名或者 ``/dev/zero`` 映射
0062 | SHARED - 映射的大小
0063 | PRIVATE READ-only - 0 cost (但作用不大)
0064 | PRIVATE WRITABLE - 每个实例的映射大小
0065
0066 额外的计数
0067 | 通过mmap制作可写副本的页面
0068 | 从同一池中提取的shmfs内存
0069
0070 状态
0071 ====
0072
0073 * 我们核算mmap内存映射
0074 * 我们核算mprotect在提交中的变化
0075 * 我们核算mremap的大小变化
0076 * 我们的审计 brk
0077 * 审计munmap
0078 * 我们在/proc中报告commit 状态
0079 * 核对并检查分叉的情况
0080 * 审查堆栈处理/执行中的构建
0081 * 叙述SHMfs的情况
0082 * 实现实际限制的执行
0083
0084 待续
0085 ====
0086 * ptrace 页计数（这很难）。
