cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

overcommit-accounting.rst (2740B)


      1.. _overcommit_accounting:
      2
      3=====================
      4Overcommit Accounting
      5=====================
      6
      7The Linux kernel supports the following overcommit handling modes
      8
      90
     10	Heuristic overcommit handling. Obvious overcommits of address
     11	space are refused. Used for a typical system. It ensures a
     12	seriously wild allocation fails while allowing overcommit to
     13	reduce swap usage.  root is allowed to allocate slightly more
     14	memory in this mode. This is the default.
     15
     161
     17	Always overcommit. Appropriate for some scientific
     18	applications. Classic example is code using sparse arrays and
     19	just relying on the virtual memory consisting almost entirely
     20	of zero pages.
     21
     222
     23	Don't overcommit. The total address space commit for the
     24	system is not permitted to exceed swap + a configurable amount
     25	(default is 50%) of physical RAM.  Depending on the amount you
     26	use, in most situations this means a process will not be
     27	killed while accessing pages but will receive errors on memory
     28	allocation as appropriate.
     29
     30	Useful for applications that want to guarantee their memory
     31	allocations will be available in the future without having to
     32	initialize every page.
     33
     34The overcommit policy is set via the sysctl ``vm.overcommit_memory``.
     35
     36The overcommit amount can be set via ``vm.overcommit_ratio`` (percentage)
     37or ``vm.overcommit_kbytes`` (absolute value). These only have an effect
     38when ``vm.overcommit_memory`` is set to 2.
     39
     40The current overcommit limit and amount committed are viewable in
     41``/proc/meminfo`` as CommitLimit and Committed_AS respectively.
     42
     43Gotchas
     44=======
     45
     46The C language stack growth does an implicit mremap. If you want absolute
     47guarantees and run close to the edge you MUST mmap your stack for the
     48largest size you think you will need. For typical stack usage this does
     49not matter much but it's a corner case if you really really care
     50
     51In mode 2 the MAP_NORESERVE flag is ignored.
     52
     53
     54How It Works
     55============
     56
     57The overcommit is based on the following rules
     58
     59For a file backed map
     60	| SHARED or READ-only	-	0 cost (the file is the map not swap)
     61	| PRIVATE WRITABLE	-	size of mapping per instance
     62
     63For an anonymous or ``/dev/zero`` map
     64	| SHARED			-	size of mapping
     65	| PRIVATE READ-only	-	0 cost (but of little use)
     66	| PRIVATE WRITABLE	-	size of mapping per instance
     67
     68Additional accounting
     69	| Pages made writable copies by mmap
     70	| shmfs memory drawn from the same pool
     71
     72Status
     73======
     74
     75*	We account mmap memory mappings
     76*	We account mprotect changes in commit
     77*	We account mremap changes in size
     78*	We account brk
     79*	We account munmap
     80*	We report the commit status in /proc
     81*	Account and check on fork
     82*	Review stack handling/building on exec
     83*	SHMfs accounting
     84*	Implement actual limit enforcement
     85
     86To Do
     87=====
     88*	Account ptrace pages (this is hard)