| 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 ================================= |