| 1 | =====================
|
| 2 | Overcommit Accounting
|
| 3 | =====================
|
| 4 |
|
| 5 | The Linux kernel supports the following overcommit handling modes
|
| 6 |
|
| 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.
|
| 12 |
|
| 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.
|
| 18 |
|
| 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.
|
| 26 |
|
| 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.
|
| 30 |
|
| 31 | The overcommit policy is set via the sysctl ``vm.overcommit_memory``.
|
| 32 |
|
| 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.
|
| 36 |
|
| 37 | The current overcommit limit and amount committed are viewable in
|
| 38 | ``/proc/meminfo`` as CommitLimit and Committed_AS respectively.
|
| 39 |
|
| 40 | Gotchas
|
| 41 | =======
|
| 42 |
|
| 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
|
| 47 |
|
| 48 | In mode 2 the MAP_NORESERVE flag is ignored.
|
| 49 |
|
| 50 |
|
| 51 | How It Works
|
| 52 | ============
|
| 53 |
|
| 54 | The overcommit is based on the following rules
|
| 55 |
|
| 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
|
| 59 |
|
| 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
|
| 64 |
|
| 65 | Additional accounting
|
| 66 | | Pages made writable copies by mmap
|
| 67 | | shmfs memory drawn from the same pool
|
| 68 |
|
| 69 | Status
|
| 70 | ======
|
| 71 |
|
| 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
|
| 82 |
|
| 83 | To Do
|
| 84 | =====
|
| 85 | * Account ptrace pages (this is hard)
|