Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 1 | Documentation for /proc/sys/vm/* kernel version 2.6.29 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 2 | (c) 1998, 1999, Rik van Riel <riel@nl.linux.org> |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 3 | (c) 2008 Peter W. Morreale <pmorreale@novell.com> |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 4 | |
| 5 | For general info and legal blurb, please look in README. |
| 6 | |
| 7 | ============================================================== |
| 8 | |
| 9 | This file contains the documentation for the sysctl files in |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 10 | /proc/sys/vm and is valid for Linux kernel version 2.6.29. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 11 | |
| 12 | The files in this directory can be used to tune the operation |
| 13 | of the virtual memory (VM) subsystem of the Linux kernel and |
| 14 | the writeout of dirty data to disk. |
| 15 | |
| 16 | Default values and initialization routines for most of these |
| 17 | files can be found in mm/swap.c. |
| 18 | |
| 19 | Currently, these files are in /proc/sys/vm: |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 20 | |
| 21 | - block_dump |
| 22 | - dirty_background_bytes |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 23 | - dirty_background_ratio |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 24 | - dirty_bytes |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 25 | - dirty_expire_centisecs |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 26 | - dirty_ratio |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 27 | - dirty_writeback_centisecs |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 28 | - drop_caches |
| 29 | - hugepages_treat_as_movable |
| 30 | - hugetlb_shm_group |
| 31 | - laptop_mode |
| 32 | - legacy_va_layout |
| 33 | - lowmem_reserve_ratio |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 34 | - max_map_count |
| 35 | - min_free_kbytes |
Christoph Lameter | 0ff3849 | 2006-09-25 23:31:52 -0700 | [diff] [blame] | 36 | - min_slab_ratio |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 37 | - min_unmapped_ratio |
| 38 | - mmap_min_addr |
Nishanth Aravamudan | d5dbac8 | 2007-12-17 16:20:25 -0800 | [diff] [blame] | 39 | - nr_hugepages |
| 40 | - nr_overcommit_hugepages |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 41 | - nr_pdflush_threads |
| 42 | - nr_trim_pages (only if CONFIG_MMU=n) |
| 43 | - numa_zonelist_order |
| 44 | - oom_dump_tasks |
| 45 | - oom_kill_allocating_task |
| 46 | - overcommit_memory |
| 47 | - overcommit_ratio |
| 48 | - page-cluster |
| 49 | - panic_on_oom |
| 50 | - percpu_pagelist_fraction |
| 51 | - stat_interval |
| 52 | - swappiness |
| 53 | - vfs_cache_pressure |
| 54 | - zone_reclaim_mode |
| 55 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 56 | |
| 57 | ============================================================== |
| 58 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 59 | block_dump |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 60 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 61 | block_dump enables block I/O debugging when set to a nonzero value. More |
| 62 | information on block I/O debugging is in Documentation/laptops/laptop-mode.txt. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 63 | |
| 64 | ============================================================== |
| 65 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 66 | dirty_background_bytes |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 67 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 68 | Contains the amount of dirty memory at which the pdflush background writeback |
| 69 | daemon will start writeback. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 70 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 71 | If dirty_background_bytes is written, dirty_background_ratio becomes a function |
| 72 | of its value (dirty_background_bytes / the amount of dirtyable system memory). |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 73 | |
| 74 | ============================================================== |
| 75 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 76 | dirty_background_ratio |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 77 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 78 | Contains, as a percentage of total system memory, the number of pages at which |
| 79 | the pdflush background writeback daemon will start writing out dirty data. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 80 | |
| 81 | ============================================================== |
| 82 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 83 | dirty_bytes |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 84 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 85 | Contains the amount of dirty memory at which a process generating disk writes |
| 86 | will itself start writeback. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 87 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 88 | If dirty_bytes is written, dirty_ratio becomes a function of its value |
| 89 | (dirty_bytes / the amount of dirtyable system memory). |
| 90 | |
Andrea Righi | 9e4a5bd | 2009-04-30 15:08:57 -0700 | [diff] [blame] | 91 | Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any |
| 92 | value lower than this limit will be ignored and the old configuration will be |
| 93 | retained. |
| 94 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 95 | ============================================================== |
| 96 | |
| 97 | dirty_expire_centisecs |
| 98 | |
| 99 | This tunable is used to define when dirty data is old enough to be eligible |
| 100 | for writeout by the pdflush daemons. It is expressed in 100'ths of a second. |
| 101 | Data which has been dirty in-memory for longer than this interval will be |
| 102 | written out next time a pdflush daemon wakes up. |
| 103 | |
| 104 | ============================================================== |
| 105 | |
| 106 | dirty_ratio |
| 107 | |
| 108 | Contains, as a percentage of total system memory, the number of pages at which |
| 109 | a process which is generating disk writes will itself start writing out dirty |
| 110 | data. |
| 111 | |
| 112 | ============================================================== |
| 113 | |
| 114 | dirty_writeback_centisecs |
| 115 | |
| 116 | The pdflush writeback daemons will periodically wake up and write `old' data |
| 117 | out to disk. This tunable expresses the interval between those wakeups, in |
| 118 | 100'ths of a second. |
| 119 | |
| 120 | Setting this to zero disables periodic writeback altogether. |
| 121 | |
| 122 | ============================================================== |
| 123 | |
| 124 | drop_caches |
| 125 | |
| 126 | Writing to this will cause the kernel to drop clean caches, dentries and |
| 127 | inodes from memory, causing that memory to become free. |
| 128 | |
| 129 | To free pagecache: |
| 130 | echo 1 > /proc/sys/vm/drop_caches |
| 131 | To free dentries and inodes: |
| 132 | echo 2 > /proc/sys/vm/drop_caches |
| 133 | To free pagecache, dentries and inodes: |
| 134 | echo 3 > /proc/sys/vm/drop_caches |
| 135 | |
| 136 | As this is a non-destructive operation and dirty objects are not freeable, the |
| 137 | user should run `sync' first. |
| 138 | |
| 139 | ============================================================== |
| 140 | |
| 141 | hugepages_treat_as_movable |
| 142 | |
| 143 | This parameter is only useful when kernelcore= is specified at boot time to |
| 144 | create ZONE_MOVABLE for pages that may be reclaimed or migrated. Huge pages |
| 145 | are not movable so are not normally allocated from ZONE_MOVABLE. A non-zero |
| 146 | value written to hugepages_treat_as_movable allows huge pages to be allocated |
| 147 | from ZONE_MOVABLE. |
| 148 | |
| 149 | Once enabled, the ZONE_MOVABLE is treated as an area of memory the huge |
| 150 | pages pool can easily grow or shrink within. Assuming that applications are |
| 151 | not running that mlock() a lot of memory, it is likely the huge pages pool |
| 152 | can grow to the size of ZONE_MOVABLE by repeatedly entering the desired value |
| 153 | into nr_hugepages and triggering page reclaim. |
| 154 | |
| 155 | ============================================================== |
| 156 | |
| 157 | hugetlb_shm_group |
| 158 | |
| 159 | hugetlb_shm_group contains group id that is allowed to create SysV |
| 160 | shared memory segment using hugetlb page. |
| 161 | |
| 162 | ============================================================== |
| 163 | |
| 164 | laptop_mode |
| 165 | |
| 166 | laptop_mode is a knob that controls "laptop mode". All the things that are |
| 167 | controlled by this knob are discussed in Documentation/laptops/laptop-mode.txt. |
| 168 | |
| 169 | ============================================================== |
| 170 | |
| 171 | legacy_va_layout |
| 172 | |
| 173 | If non-zero, this sysctl disables the new 32-bit mmap mmap layout - the kernel |
| 174 | will use the legacy (2.4) layout for all processes. |
| 175 | |
| 176 | ============================================================== |
| 177 | |
| 178 | lowmem_reserve_ratio |
| 179 | |
| 180 | For some specialised workloads on highmem machines it is dangerous for |
| 181 | the kernel to allow process memory to be allocated from the "lowmem" |
| 182 | zone. This is because that memory could then be pinned via the mlock() |
| 183 | system call, or by unavailability of swapspace. |
| 184 | |
| 185 | And on large highmem machines this lack of reclaimable lowmem memory |
| 186 | can be fatal. |
| 187 | |
| 188 | So the Linux page allocator has a mechanism which prevents allocations |
| 189 | which _could_ use highmem from using too much lowmem. This means that |
| 190 | a certain amount of lowmem is defended from the possibility of being |
| 191 | captured into pinned user memory. |
| 192 | |
| 193 | (The same argument applies to the old 16 megabyte ISA DMA region. This |
| 194 | mechanism will also defend that region from allocations which could use |
| 195 | highmem or lowmem). |
| 196 | |
| 197 | The `lowmem_reserve_ratio' tunable determines how aggressive the kernel is |
| 198 | in defending these lower zones. |
| 199 | |
| 200 | If you have a machine which uses highmem or ISA DMA and your |
| 201 | applications are using mlock(), or if you are running with no swap then |
| 202 | you probably should change the lowmem_reserve_ratio setting. |
| 203 | |
| 204 | The lowmem_reserve_ratio is an array. You can see them by reading this file. |
| 205 | - |
| 206 | % cat /proc/sys/vm/lowmem_reserve_ratio |
| 207 | 256 256 32 |
| 208 | - |
| 209 | Note: # of this elements is one fewer than number of zones. Because the highest |
| 210 | zone's value is not necessary for following calculation. |
| 211 | |
| 212 | But, these values are not used directly. The kernel calculates # of protection |
| 213 | pages for each zones from them. These are shown as array of protection pages |
| 214 | in /proc/zoneinfo like followings. (This is an example of x86-64 box). |
| 215 | Each zone has an array of protection pages like this. |
| 216 | |
| 217 | - |
| 218 | Node 0, zone DMA |
| 219 | pages free 1355 |
| 220 | min 3 |
| 221 | low 3 |
| 222 | high 4 |
| 223 | : |
| 224 | : |
| 225 | numa_other 0 |
| 226 | protection: (0, 2004, 2004, 2004) |
| 227 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 228 | pagesets |
| 229 | cpu: 0 pcp: 0 |
| 230 | : |
| 231 | - |
| 232 | These protections are added to score to judge whether this zone should be used |
| 233 | for page allocation or should be reclaimed. |
| 234 | |
| 235 | In this example, if normal pages (index=2) are required to this DMA zone and |
Mel Gorman | 4185896 | 2009-06-16 15:32:12 -0700 | [diff] [blame] | 236 | watermark[WMARK_HIGH] is used for watermark, the kernel judges this zone should |
| 237 | not be used because pages_free(1355) is smaller than watermark + protection[2] |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 238 | (4 + 2004 = 2008). If this protection value is 0, this zone would be used for |
| 239 | normal page requirement. If requirement is DMA zone(index=0), protection[0] |
| 240 | (=0) is used. |
| 241 | |
| 242 | zone[i]'s protection[j] is calculated by following expression. |
| 243 | |
| 244 | (i < j): |
| 245 | zone[i]->protection[j] |
| 246 | = (total sums of present_pages from zone[i+1] to zone[j] on the node) |
| 247 | / lowmem_reserve_ratio[i]; |
| 248 | (i = j): |
| 249 | (should not be protected. = 0; |
| 250 | (i > j): |
| 251 | (not necessary, but looks 0) |
| 252 | |
| 253 | The default values of lowmem_reserve_ratio[i] are |
| 254 | 256 (if zone[i] means DMA or DMA32 zone) |
| 255 | 32 (others). |
| 256 | As above expression, they are reciprocal number of ratio. |
| 257 | 256 means 1/256. # of protection pages becomes about "0.39%" of total present |
| 258 | pages of higher zones on the node. |
| 259 | |
| 260 | If you would like to protect more pages, smaller values are effective. |
| 261 | The minimum value is 1 (1/1 -> 100%). |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 262 | |
| 263 | ============================================================== |
| 264 | |
| 265 | max_map_count: |
| 266 | |
| 267 | This file contains the maximum number of memory map areas a process |
| 268 | may have. Memory map areas are used as a side-effect of calling |
| 269 | malloc, directly by mmap and mprotect, and also when loading shared |
| 270 | libraries. |
| 271 | |
| 272 | While most applications need less than a thousand maps, certain |
| 273 | programs, particularly malloc debuggers, may consume lots of them, |
| 274 | e.g., up to one or two maps per allocation. |
| 275 | |
| 276 | The default value is 65536. |
| 277 | |
| 278 | ============================================================== |
| 279 | |
| 280 | min_free_kbytes: |
| 281 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 282 | This is used to force the Linux VM to keep a minimum number |
Mel Gorman | 4185896 | 2009-06-16 15:32:12 -0700 | [diff] [blame] | 283 | of kilobytes free. The VM uses this number to compute a |
| 284 | watermark[WMARK_MIN] value for each lowmem zone in the system. |
| 285 | Each lowmem zone gets a number of reserved free pages based |
| 286 | proportionally on its size. |
Rohit Seth | 8ad4b1f | 2006-01-08 01:00:40 -0800 | [diff] [blame] | 287 | |
Matt LaPlante | d919588 | 2008-07-25 19:45:33 -0700 | [diff] [blame] | 288 | Some minimal amount of memory is needed to satisfy PF_MEMALLOC |
Pavel Machek | 2495089 | 2007-10-16 23:31:28 -0700 | [diff] [blame] | 289 | allocations; if you set this to lower than 1024KB, your system will |
| 290 | become subtly broken, and prone to deadlock under high loads. |
| 291 | |
| 292 | Setting this too high will OOM your machine instantly. |
| 293 | |
Christoph Lameter | 9614634 | 2006-07-03 00:24:13 -0700 | [diff] [blame] | 294 | ============================================================= |
| 295 | |
Christoph Lameter | 0ff3849 | 2006-09-25 23:31:52 -0700 | [diff] [blame] | 296 | min_slab_ratio: |
| 297 | |
| 298 | This is available only on NUMA kernels. |
| 299 | |
| 300 | A percentage of the total pages in each zone. On Zone reclaim |
| 301 | (fallback from the local zone occurs) slabs will be reclaimed if more |
| 302 | than this percentage of pages in a zone are reclaimable slab pages. |
| 303 | This insures that the slab growth stays under control even in NUMA |
| 304 | systems that rarely perform global reclaim. |
| 305 | |
| 306 | The default is 5 percent. |
| 307 | |
| 308 | Note that slab reclaim is triggered in a per zone / node fashion. |
| 309 | The process of reclaiming slab memory is currently not node specific |
| 310 | and may not be fast. |
| 311 | |
| 312 | ============================================================= |
| 313 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 314 | min_unmapped_ratio: |
KAMEZAWA Hiroyuki | fadd8fb | 2006-06-23 02:03:13 -0700 | [diff] [blame] | 315 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 316 | This is available only on NUMA kernels. |
Yasunori Goto | 2b744c0 | 2007-05-06 14:49:59 -0700 | [diff] [blame] | 317 | |
Mel Gorman | 90afa5d | 2009-06-16 15:33:20 -0700 | [diff] [blame] | 318 | This is a percentage of the total pages in each zone. Zone reclaim will |
| 319 | only occur if more than this percentage of pages are in a state that |
| 320 | zone_reclaim_mode allows to be reclaimed. |
| 321 | |
| 322 | If zone_reclaim_mode has the value 4 OR'd, then the percentage is compared |
| 323 | against all file-backed unmapped pages including swapcache pages and tmpfs |
| 324 | files. Otherwise, only unmapped pages backed by normal files but not tmpfs |
| 325 | files and similar are considered. |
Yasunori Goto | 2b744c0 | 2007-05-06 14:49:59 -0700 | [diff] [blame] | 326 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 327 | The default is 1 percent. |
David Rientjes | fe071d7 | 2007-10-16 23:25:56 -0700 | [diff] [blame] | 328 | |
Eric Paris | ed03218 | 2007-06-28 15:55:21 -0400 | [diff] [blame] | 329 | ============================================================== |
| 330 | |
| 331 | mmap_min_addr |
| 332 | |
| 333 | This file indicates the amount of address space which a user process will |
| 334 | be restricted from mmaping. Since kernel null dereference bugs could |
| 335 | accidentally operate based on the information in the first couple of pages |
| 336 | of memory userspace processes should not be allowed to write to them. By |
| 337 | default this value is set to 0 and no protections will be enforced by the |
| 338 | security module. Setting this value to something like 64k will allow the |
| 339 | vast majority of applications to work correctly and provide defense in depth |
| 340 | against future potential kernel bugs. |
| 341 | |
KAMEZAWA Hiroyuki | f0c0b2b | 2007-07-15 23:38:01 -0700 | [diff] [blame] | 342 | ============================================================== |
| 343 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 344 | nr_hugepages |
| 345 | |
| 346 | Change the minimum size of the hugepage pool. |
| 347 | |
| 348 | See Documentation/vm/hugetlbpage.txt |
| 349 | |
| 350 | ============================================================== |
| 351 | |
| 352 | nr_overcommit_hugepages |
| 353 | |
| 354 | Change the maximum size of the hugepage pool. The maximum is |
| 355 | nr_hugepages + nr_overcommit_hugepages. |
| 356 | |
| 357 | See Documentation/vm/hugetlbpage.txt |
| 358 | |
| 359 | ============================================================== |
| 360 | |
| 361 | nr_pdflush_threads |
| 362 | |
| 363 | The current number of pdflush threads. This value is read-only. |
| 364 | The value changes according to the number of dirty pages in the system. |
| 365 | |
Matt LaPlante | 19f5946 | 2009-04-27 15:06:31 +0200 | [diff] [blame] | 366 | When necessary, additional pdflush threads are created, one per second, up to |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 367 | nr_pdflush_threads_max. |
| 368 | |
| 369 | ============================================================== |
| 370 | |
| 371 | nr_trim_pages |
| 372 | |
| 373 | This is available only on NOMMU kernels. |
| 374 | |
| 375 | This value adjusts the excess page trimming behaviour of power-of-2 aligned |
| 376 | NOMMU mmap allocations. |
| 377 | |
| 378 | A value of 0 disables trimming of allocations entirely, while a value of 1 |
| 379 | trims excess pages aggressively. Any value >= 1 acts as the watermark where |
| 380 | trimming of allocations is initiated. |
| 381 | |
| 382 | The default value is 1. |
| 383 | |
| 384 | See Documentation/nommu-mmap.txt for more information. |
| 385 | |
| 386 | ============================================================== |
| 387 | |
KAMEZAWA Hiroyuki | f0c0b2b | 2007-07-15 23:38:01 -0700 | [diff] [blame] | 388 | numa_zonelist_order |
| 389 | |
| 390 | This sysctl is only for NUMA. |
| 391 | 'where the memory is allocated from' is controlled by zonelists. |
| 392 | (This documentation ignores ZONE_HIGHMEM/ZONE_DMA32 for simple explanation. |
| 393 | you may be able to read ZONE_DMA as ZONE_DMA32...) |
| 394 | |
| 395 | In non-NUMA case, a zonelist for GFP_KERNEL is ordered as following. |
| 396 | ZONE_NORMAL -> ZONE_DMA |
| 397 | This means that a memory allocation request for GFP_KERNEL will |
| 398 | get memory from ZONE_DMA only when ZONE_NORMAL is not available. |
| 399 | |
| 400 | In NUMA case, you can think of following 2 types of order. |
| 401 | Assume 2 node NUMA and below is zonelist of Node(0)'s GFP_KERNEL |
| 402 | |
| 403 | (A) Node(0) ZONE_NORMAL -> Node(0) ZONE_DMA -> Node(1) ZONE_NORMAL |
| 404 | (B) Node(0) ZONE_NORMAL -> Node(1) ZONE_NORMAL -> Node(0) ZONE_DMA. |
| 405 | |
| 406 | Type(A) offers the best locality for processes on Node(0), but ZONE_DMA |
| 407 | will be used before ZONE_NORMAL exhaustion. This increases possibility of |
| 408 | out-of-memory(OOM) of ZONE_DMA because ZONE_DMA is tend to be small. |
| 409 | |
| 410 | Type(B) cannot offer the best locality but is more robust against OOM of |
| 411 | the DMA zone. |
| 412 | |
| 413 | Type(A) is called as "Node" order. Type (B) is "Zone" order. |
| 414 | |
| 415 | "Node order" orders the zonelists by node, then by zone within each node. |
| 416 | Specify "[Nn]ode" for zone order |
| 417 | |
| 418 | "Zone Order" orders the zonelists by zone type, then by node within each |
| 419 | zone. Specify "[Zz]one"for zode order. |
| 420 | |
| 421 | Specify "[Dd]efault" to request automatic configuration. Autoconfiguration |
| 422 | will select "node" order in following case. |
| 423 | (1) if the DMA zone does not exist or |
| 424 | (2) if the DMA zone comprises greater than 50% of the available memory or |
| 425 | (3) if any node's DMA zone comprises greater than 60% of its local memory and |
| 426 | the amount of local memory is big enough. |
| 427 | |
| 428 | Otherwise, "zone" order will be selected. Default order is recommended unless |
| 429 | this is causing problems for your system/application. |
Nishanth Aravamudan | d5dbac8 | 2007-12-17 16:20:25 -0800 | [diff] [blame] | 430 | |
| 431 | ============================================================== |
| 432 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 433 | oom_dump_tasks |
Nishanth Aravamudan | d5dbac8 | 2007-12-17 16:20:25 -0800 | [diff] [blame] | 434 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 435 | Enables a system-wide task dump (excluding kernel threads) to be |
| 436 | produced when the kernel performs an OOM-killing and includes such |
| 437 | information as pid, uid, tgid, vm size, rss, cpu, oom_adj score, and |
| 438 | name. This is helpful to determine why the OOM killer was invoked |
| 439 | and to identify the rogue task that caused it. |
Nishanth Aravamudan | d5dbac8 | 2007-12-17 16:20:25 -0800 | [diff] [blame] | 440 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 441 | If this is set to zero, this information is suppressed. On very |
| 442 | large systems with thousands of tasks it may not be feasible to dump |
| 443 | the memory state information for each one. Such systems should not |
| 444 | be forced to incur a performance penalty in OOM conditions when the |
| 445 | information may not be desired. |
| 446 | |
| 447 | If this is set to non-zero, this information is shown whenever the |
| 448 | OOM killer actually kills a memory-hogging task. |
| 449 | |
| 450 | The default value is 0. |
Nishanth Aravamudan | d5dbac8 | 2007-12-17 16:20:25 -0800 | [diff] [blame] | 451 | |
| 452 | ============================================================== |
| 453 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 454 | oom_kill_allocating_task |
Nishanth Aravamudan | d5dbac8 | 2007-12-17 16:20:25 -0800 | [diff] [blame] | 455 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 456 | This enables or disables killing the OOM-triggering task in |
| 457 | out-of-memory situations. |
Nishanth Aravamudan | d5dbac8 | 2007-12-17 16:20:25 -0800 | [diff] [blame] | 458 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 459 | If this is set to zero, the OOM killer will scan through the entire |
| 460 | tasklist and select a task based on heuristics to kill. This normally |
| 461 | selects a rogue memory-hogging task that frees up a large amount of |
| 462 | memory when killed. |
| 463 | |
| 464 | If this is set to non-zero, the OOM killer simply kills the task that |
| 465 | triggered the out-of-memory condition. This avoids the expensive |
| 466 | tasklist scan. |
| 467 | |
| 468 | If panic_on_oom is selected, it takes precedence over whatever value |
| 469 | is used in oom_kill_allocating_task. |
| 470 | |
| 471 | The default value is 0. |
Paul Mundt | dd8632a | 2009-01-08 12:04:47 +0000 | [diff] [blame] | 472 | |
| 473 | ============================================================== |
| 474 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 475 | overcommit_memory: |
Paul Mundt | dd8632a | 2009-01-08 12:04:47 +0000 | [diff] [blame] | 476 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 477 | This value contains a flag that enables memory overcommitment. |
Paul Mundt | dd8632a | 2009-01-08 12:04:47 +0000 | [diff] [blame] | 478 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 479 | When this flag is 0, the kernel attempts to estimate the amount |
| 480 | of free memory left when userspace requests more memory. |
Paul Mundt | dd8632a | 2009-01-08 12:04:47 +0000 | [diff] [blame] | 481 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 482 | When this flag is 1, the kernel pretends there is always enough |
| 483 | memory until it actually runs out. |
Paul Mundt | dd8632a | 2009-01-08 12:04:47 +0000 | [diff] [blame] | 484 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 485 | When this flag is 2, the kernel uses a "never overcommit" |
| 486 | policy that attempts to prevent any overcommit of memory. |
Paul Mundt | dd8632a | 2009-01-08 12:04:47 +0000 | [diff] [blame] | 487 | |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 488 | This feature can be very useful because there are a lot of |
| 489 | programs that malloc() huge amounts of memory "just-in-case" |
| 490 | and don't use much of it. |
| 491 | |
| 492 | The default value is 0. |
| 493 | |
| 494 | See Documentation/vm/overcommit-accounting and |
| 495 | security/commoncap.c::cap_vm_enough_memory() for more information. |
| 496 | |
| 497 | ============================================================== |
| 498 | |
| 499 | overcommit_ratio: |
| 500 | |
| 501 | When overcommit_memory is set to 2, the committed address |
| 502 | space is not permitted to exceed swap plus this percentage |
| 503 | of physical RAM. See above. |
| 504 | |
| 505 | ============================================================== |
| 506 | |
| 507 | page-cluster |
| 508 | |
| 509 | page-cluster controls the number of pages which are written to swap in |
| 510 | a single attempt. The swap I/O size. |
| 511 | |
| 512 | It is a logarithmic value - setting it to zero means "1 page", setting |
| 513 | it to 1 means "2 pages", setting it to 2 means "4 pages", etc. |
| 514 | |
| 515 | The default value is three (eight pages at a time). There may be some |
| 516 | small benefits in tuning this to a different value if your workload is |
| 517 | swap-intensive. |
| 518 | |
| 519 | ============================================================= |
| 520 | |
| 521 | panic_on_oom |
| 522 | |
| 523 | This enables or disables panic on out-of-memory feature. |
| 524 | |
| 525 | If this is set to 0, the kernel will kill some rogue process, |
| 526 | called oom_killer. Usually, oom_killer can kill rogue processes and |
| 527 | system will survive. |
| 528 | |
| 529 | If this is set to 1, the kernel panics when out-of-memory happens. |
| 530 | However, if a process limits using nodes by mempolicy/cpusets, |
| 531 | and those nodes become memory exhaustion status, one process |
| 532 | may be killed by oom-killer. No panic occurs in this case. |
| 533 | Because other nodes' memory may be free. This means system total status |
| 534 | may be not fatal yet. |
| 535 | |
| 536 | If this is set to 2, the kernel panics compulsorily even on the |
| 537 | above-mentioned. |
| 538 | |
| 539 | The default value is 0. |
| 540 | 1 and 2 are for failover of clustering. Please select either |
| 541 | according to your policy of failover. |
| 542 | |
| 543 | ============================================================= |
| 544 | |
| 545 | percpu_pagelist_fraction |
| 546 | |
| 547 | This is the fraction of pages at most (high mark pcp->high) in each zone that |
| 548 | are allocated for each per cpu page list. The min value for this is 8. It |
| 549 | means that we don't allow more than 1/8th of pages in each zone to be |
| 550 | allocated in any single per_cpu_pagelist. This entry only changes the value |
| 551 | of hot per cpu pagelists. User can specify a number like 100 to allocate |
| 552 | 1/100th of each zone to each per cpu page list. |
| 553 | |
| 554 | The batch value of each per cpu pagelist is also updated as a result. It is |
| 555 | set to pcp->high/4. The upper limit of batch is (PAGE_SHIFT * 8) |
| 556 | |
| 557 | The initial value is zero. Kernel does not use this value at boot time to set |
| 558 | the high water marks for each per cpu page list. |
| 559 | |
| 560 | ============================================================== |
| 561 | |
| 562 | stat_interval |
| 563 | |
| 564 | The time interval between which vm statistics are updated. The default |
| 565 | is 1 second. |
| 566 | |
| 567 | ============================================================== |
| 568 | |
| 569 | swappiness |
| 570 | |
| 571 | This control is used to define how aggressive the kernel will swap |
| 572 | memory pages. Higher values will increase agressiveness, lower values |
Matt LaPlante | 19f5946 | 2009-04-27 15:06:31 +0200 | [diff] [blame] | 573 | decrease the amount of swap. |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 574 | |
| 575 | The default value is 60. |
| 576 | |
| 577 | ============================================================== |
| 578 | |
| 579 | vfs_cache_pressure |
| 580 | ------------------ |
| 581 | |
| 582 | Controls the tendency of the kernel to reclaim the memory which is used for |
| 583 | caching of directory and inode objects. |
| 584 | |
| 585 | At the default value of vfs_cache_pressure=100 the kernel will attempt to |
| 586 | reclaim dentries and inodes at a "fair" rate with respect to pagecache and |
| 587 | swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer |
Jan Kara | 55c37a8 | 2009-09-21 17:01:40 -0700 | [diff] [blame^] | 588 | to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will |
| 589 | never reclaim dentries and inodes due to memory pressure and this can easily |
| 590 | lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 |
Peter W Morreale | db0fb18 | 2009-01-15 13:50:42 -0800 | [diff] [blame] | 591 | causes the kernel to prefer to reclaim dentries and inodes. |
| 592 | |
| 593 | ============================================================== |
| 594 | |
| 595 | zone_reclaim_mode: |
| 596 | |
| 597 | Zone_reclaim_mode allows someone to set more or less aggressive approaches to |
| 598 | reclaim memory when a zone runs out of memory. If it is set to zero then no |
| 599 | zone reclaim occurs. Allocations will be satisfied from other zones / nodes |
| 600 | in the system. |
| 601 | |
| 602 | This is value ORed together of |
| 603 | |
| 604 | 1 = Zone reclaim on |
| 605 | 2 = Zone reclaim writes dirty pages out |
| 606 | 4 = Zone reclaim swaps pages |
| 607 | |
| 608 | zone_reclaim_mode is set during bootup to 1 if it is determined that pages |
| 609 | from remote zones will cause a measurable performance reduction. The |
| 610 | page allocator will then reclaim easily reusable pages (those page |
| 611 | cache pages that are currently not used) before allocating off node pages. |
| 612 | |
| 613 | It may be beneficial to switch off zone reclaim if the system is |
| 614 | used for a file server and all of memory should be used for caching files |
| 615 | from disk. In that case the caching effect is more important than |
| 616 | data locality. |
| 617 | |
| 618 | Allowing zone reclaim to write out pages stops processes that are |
| 619 | writing large amounts of data from dirtying pages on other nodes. Zone |
| 620 | reclaim will write out dirty pages if a zone fills up and so effectively |
| 621 | throttle the process. This may decrease the performance of a single process |
| 622 | since it cannot use all of system memory to buffer the outgoing writes |
| 623 | anymore but it preserve the memory on other nodes so that the performance |
| 624 | of other processes running on other nodes will not be affected. |
| 625 | |
| 626 | Allowing regular swap effectively restricts allocations to the local |
| 627 | node unless explicitly overridden by memory policies or cpuset |
| 628 | configurations. |
| 629 | |
| 630 | ============ End of Document ================================= |