87 lines · plain
1:Original: Documentation/mm/overcommit-accounting.rst2 3:翻译:4 5 司延腾 Yanteng Si <siyanteng@loongson.cn>6 7:校译:8 9 10 11==============12超量使用审计13==============14 15Linux内核支持下列超量使用处理模式16 17018 启发式超量使用处理。拒绝明显的地址空间超量使用。用于一个典型的系统。19 它确保严重的疯狂分配失败，同时允许超量使用以减少swap的使用。在这种模式下，20 允许root分配稍多的内存。这是默认的。21122 总是超量使用。适用于一些科学应用。经典的例子是使用稀疏数组的代码，只是依赖23 几乎完全由零页组成的虚拟内存24 25226 不超量使用。系统提交的总地址空间不允许超过swap+一个可配置的物理RAM的数量27 （默认为50%）。根据你使用的数量，在大多数情况下，这意味着一个进程在访问页面时28 不会被杀死，但会在内存分配上收到相应的错误。29 30 对于那些想保证他们的内存分配在未来可用而又不需要初始化每一个页面的应用程序来说31 是很有用的。32 33超量使用策略是通过sysctl `vm.overcommit_memory` 设置的。34 35可以通过 `vm.overcommit_ratio` （百分比）或 `vm.overcommit_kbytes` （绝对值）36来设置超限数量。这些只有在 `vm.overcommit_memory` 被设置为2时才有效果。37 38在 ``/proc/meminfo`` 中可以分别以CommitLimit和Committed_AS的形式查看当前39的超量使用和提交量。40 41陷阱42====43 44C语言的堆栈增长是一个隐含的mremap。如果你想得到绝对的保证，并在接近边缘的地方运行，45你 **必须** 为你认为你需要的最大尺寸的堆栈进行mmap。对于典型的堆栈使用来说，这并46不重要，但如果你真的非常关心的话，这就是一个值得关注的案例。47 48 49在模式2中，MAP_NORESERVE标志被忽略。50 51 52它是如何工作的53==============54 55超量使用是基于以下规则56 57对于文件映射58 | SHARED or READ-only - 0 cost (该文件是映射而不是交换)59 | PRIVATE WRITABLE - 每个实例的映射大小60 61对于匿名或者 ``/dev/zero`` 映射62 | SHARED - 映射的大小63 | PRIVATE READ-only - 0 cost (但作用不大)64 | PRIVATE WRITABLE - 每个实例的映射大小65 66额外的计数67 | 通过mmap制作可写副本的页面68 | 从同一池中提取的shmfs内存69 70状态71====72 73* 我们核算mmap内存映射74* 我们核算mprotect在提交中的变化75* 我们核算mremap的大小变化76* 我们的审计 brk77* 审计munmap78* 我们在/proc中报告commit 状态79* 核对并检查分叉的情况80* 审查堆栈处理/执行中的构建81* 叙述SHMfs的情况82* 实现实际限制的执行83 84待续85====86* ptrace 页计数（这很难）。87