요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
=====================
2
Overcommit Accounting
3
=====================
5
The Linux kernel supports the following overcommit handling modes
7
0
8
Heuristic overcommit handling. Obvious overcommits of address
9
space are refused. Used for a typical system. It ensures a
10
seriously wild allocation fails while allowing overcommit to
11
reduce swap usage. This is the default.
13
1
14
Always overcommit. Appropriate for some scientific
15
applications. Classic example is code using sparse arrays and
16
just relying on the virtual memory consisting almost entirely
17
of zero pages.
19
2
20
Don't overcommit. The total address space commit for the
21
system is not permitted to exceed swap + a configurable amount
22
(default is 50%) of physical RAM. Depending on the amount you
23
use, in most situations this means a process will not be
24
killed while accessing pages but will receive errors on memory
25
allocation as appropriate.
27
Useful for applications that want to guarantee their memory
28
allocations will be available in the future without having to
29
initialize every page.
31
The overcommit policy is set via the sysctl ``vm.overcommit_memory``.
33
The overcommit amount can be set via ``vm.overcommit_ratio`` (percentage)
34
or ``vm.overcommit_kbytes`` (absolute value). These only have an effect
35
when ``vm.overcommit_memory`` is set to 2.
37
The current overcommit limit and amount committed are viewable in
38
``/proc/meminfo`` as CommitLimit and Committed_AS respectively.
40
Gotchas
41
=======
43
The C language stack growth does an implicit mremap. If you want absolute
44
guarantees and run close to the edge you MUST mmap your stack for the
45
largest size you think you will need. For typical stack usage this does
46
not matter much but it's a corner case if you really really care
48
In mode 2 the MAP_NORESERVE flag is ignored.
51
How It Works
52
============
54
The overcommit is based on the following rules
56
For a file backed map
57
| SHARED or READ-only - 0 cost (the file is the map not swap)
58
| PRIVATE WRITABLE - size of mapping per instance
60
For an anonymous or ``/dev/zero`` map
61
| SHARED - size of mapping
62
| PRIVATE READ-only - 0 cost (but of little use)
63
| PRIVATE WRITABLE - size of mapping per instance
65
Additional accounting
66
| Pages made writable copies by mmap
67
| shmfs memory drawn from the same pool
69
Status
70
======
72
* We account mmap memory mappings
73
* We account mprotect changes in commit
74
* We account mremap changes in size
75
* We account brk
76
* We account munmap
77
* We report the commit status in /proc
78
* Account and check on fork
79
* Review stack handling/building on exec
80
* SHMfs accounting
81
* Implement actual limit enforcement
83
To Do
84
=====
85
* Account ptrace pages (this is hard)
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Overcommit 처리 모드
1-39Linux kernel은 다음 overcommit 처리 모드를 지원합니다.
- 0: Heuristic overcommit 처리입니다. 명백한 address-space overcommit을 거부합니다. 일반 system에서 사용하는 기본값입니다. 지나치게 무리한 allocation은 실패시키면서 overcommit으로 swap 사용량을 줄입니다.
- 1: 항상 overcommit합니다. 일부 scientific application에 적합합니다. Sparse array를 사용하고 virtual memory가 거의 모두 zero page로 구성된다는 점에 의존하는 code가 전형적인 예입니다.
- 2: Overcommit하지 않습니다. System의 전체 address-space commit은 swap과 설정 가능한 physical RAM 비율의 합을 넘을 수 없습니다. 기본 RAM 비율은 50%입니다. 설정량에 따라 대부분의 상황에서 process가 page 접근 중 종료되는 대신 memory allocation 시 적절한 error를 받습니다. 모든 page를 초기화하지 않고도 향후 allocation을 사용할 수 있다고 보장받으려는 application에 유용합니다.
Overcommit policy는 sysctl `vm.overcommit_memory`로 설정합니다.
Overcommit 양은 비율인 `vm.overcommit_ratio` 또는 절대값인 `vm.overcommit_kbytes`로 설정합니다. 둘은 `vm.overcommit_memory`가 2일 때만 효과가 있습니다.
현재 overcommit limit와 committed amount는 `/proc/meminfo`의 `CommitLimit`와 `Committed_AS`에서 각각 확인할 수 있습니다.
=====================
Overcommit Accounting
=====================
The Linux kernel supports the following overcommit handling modes
0
Heuristic overcommit handling. Obvious overcommits of address
space are refused. Used for a typical system. It ensures a
seriously wild allocation fails while allowing overcommit to
reduce swap usage. This is the default.
1
Always overcommit. Appropriate for some scientific
applications. Classic example is code using sparse arrays and
just relying on the virtual memory consisting almost entirely
of zero pages.
2
Don't overcommit. The total address space commit for the
system is not permitted to exceed swap + a configurable amount
(default is 50%) of physical RAM. Depending on the amount you
use, in most situations this means a process will not be
killed while accessing pages but will receive errors on memory
allocation as appropriate.
Useful for applications that want to guarantee their memory
allocations will be available in the future without having to
initialize every page.
The overcommit policy is set via the sysctl ``vm.overcommit_memory``.
The overcommit amount can be set via ``vm.overcommit_ratio`` (percentage)
or ``vm.overcommit_kbytes`` (absolute value). These only have an effect
when ``vm.overcommit_memory`` is set to 2.
The current overcommit limit and amount committed are viewable in
``/proc/meminfo`` as CommitLimit and Committed_AS respectively.
주의 사항
40-50C 언어 stack 증가는 암시적으로 `mremap`을 수행합니다. 절대적인 보장이 필요하고 limit 가까이에서 동작한다면 필요할 것으로 예상하는 최대 크기로 stack을 반드시 `mmap`해야 합니다. 일반적인 stack 사용에서는 크게 중요하지 않지만 보장을 엄격히 요구할 때의 corner case입니다.
Mode 2에서는 `MAP_NORESERVE` flag를 무시합니다.
Gotchas
=======
The C language stack growth does an implicit mremap. If you want absolute
guarantees and run close to the edge you MUST mmap your stack for the
largest size you think you will need. For typical stack usage this does
not matter much but it's a corner case if you really really care
In mode 2 the MAP_NORESERVE flag is ignored.
Commit 비용 계산 규칙
51-68Overcommit accounting은 다음 규칙을 따릅니다.
- File-backed map의 SHARED 또는 READ-only mapping: 비용 0입니다. File 자체가 map이고 swap이 아니기 때문입니다.
- File-backed map의 PRIVATE WRITABLE mapping: instance마다 mapping 크기만큼 비용이 듭니다.
- Anonymous 또는 `/dev/zero` map의 SHARED mapping: mapping 크기만큼 비용이 듭니다.
- Anonymous 또는 `/dev/zero` map의 PRIVATE READ-only mapping: 비용 0이지만 쓸모는 적습니다.
- Anonymous 또는 `/dev/zero` map의 PRIVATE WRITABLE mapping: instance마다 mapping 크기만큼 비용이 듭니다.
추가 accounting에는 `mmap`으로 writable copy가 된 page와 같은 pool에서 가져오는 shmfs memory가 포함됩니다.
How It Works
============
The overcommit is based on the following rules
For a file backed map
| SHARED or READ-only - 0 cost (the file is the map not swap)
| PRIVATE WRITABLE - size of mapping per instance
For an anonymous or ``/dev/zero`` map
| SHARED - size of mapping
| PRIVATE READ-only - 0 cost (but of little use)
| PRIVATE WRITABLE - size of mapping per instance
Additional accounting
| Pages made writable copies by mmap
| shmfs memory drawn from the same pool
구현 상태와 할 일
69-85현재 상태는 다음과 같습니다.
- `mmap` memory mapping을 account합니다.
- `mprotect`의 commit 변경을 account합니다.
- `mremap`의 크기 변경을 account합니다.
- `brk`와 `munmap`을 account합니다.
- `/proc`에 commit 상태를 보고합니다.
- `fork`에서 account하고 검사합니다.
- `exec`의 stack 처리와 생성을 검토합니다.
- SHMfs accounting을 수행합니다.
- 실제 limit enforcement를 구현합니다.
할 일은 `ptrace` page accounting이며 어려운 작업입니다.
Status
======
* We account mmap memory mappings
* We account mprotect changes in commit
* We account mremap changes in size
* We account brk
* We account munmap
* We report the commit status in /proc
* Account and check on fork
* Review stack handling/building on exec
* SHMfs accounting
* Implement actual limit enforcement
To Do
=====
* Account ptrace pages (this is hard)
요약·해설
overcommit-accounting.rst:1-85Overcommit accounting은 virtual address를 약속한 양과 실제 backing 가능량을 비교하는 정책입니다. Mode 0은 heuristic, mode 1은 무조건 허용, mode 2는 swap과 설정된 RAM 몫을 넘는 commit을 거부합니다. 비용은 mapping이 private writable copy를 요구하는지에 따라 달라집니다.
Allocation 실패 시점과 보장 수준이 다릅니다.
Private writable mapping은 instance별 copy 가능성을 account합니다.