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