| 1 | ===============================
|
| 2 | Documentation for /proc/sys/vm/
|
| 3 | ===============================
|
| 4 |
|
| 5 | kernel version 2.6.29
|
| 6 |
|
| 7 | Copyright (c) 1998, 1999, Rik van Riel <[email protected]>
|
| 8 |
|
| 9 | Copyright (c) 2008 Peter W. Morreale <[email protected]>
|
| 10 |
|
| 11 | For general info and legal blurb, please look in index.rst.
|
| 12 |
|
| 13 | ------------------------------------------------------------------------------
|
| 14 |
|
| 15 | This file contains the documentation for the sysctl files in
|
| 16 | /proc/sys/vm and is valid for Linux kernel version 2.6.29.
|
| 17 |
|
| 18 | The files in this directory can be used to tune the operation
|
| 19 | of the virtual memory (VM) subsystem of the Linux kernel and
|
| 20 | the writeout of dirty data to disk.
|
| 21 |
|
| 22 | Currently, these files are in /proc/sys/vm:
|
| 23 |
|
| 24 | - admin_reserve_kbytes
|
| 25 | - compact_memory
|
| 26 | - compaction_proactiveness
|
| 27 | - compact_unevictable_allowed
|
| 28 | - defrag_mode
|
| 29 | - dirty_background_bytes
|
| 30 | - dirty_background_ratio
|
| 31 | - dirty_bytes
|
| 32 | - dirty_expire_centisecs
|
| 33 | - dirty_ratio
|
| 34 | - dirtytime_expire_seconds
|
| 35 | - dirty_writeback_centisecs
|
| 36 | - drop_caches
|
| 37 | - enable_soft_offline
|
| 38 | - extfrag_threshold
|
| 39 | - highmem_is_dirtyable
|
| 40 | - hugetlb_shm_group
|
| 41 | - legacy_va_layout
|
| 42 | - lowmem_reserve_ratio
|
| 43 | - max_map_count
|
| 44 | - mem_profiling (only if CONFIG_MEM_ALLOC_PROFILING=y)
|
| 45 | - memory_failure_early_kill
|
| 46 | - memory_failure_recovery
|
| 47 | - min_free_kbytes
|
| 48 | - min_slab_ratio
|
| 49 | - min_unmapped_ratio
|
| 50 | - mmap_min_addr
|
| 51 | - mmap_rnd_bits
|
| 52 | - mmap_rnd_compat_bits
|
| 53 | - movable_gigantic_pages
|
| 54 | - nr_hugepages
|
| 55 | - nr_hugepages_mempolicy
|
| 56 | - nr_overcommit_hugepages
|
| 57 | - nr_trim_pages (only if CONFIG_MMU=n)
|
| 58 | - numa_zonelist_order
|
| 59 | - oom_dump_tasks
|
| 60 | - oom_kill_allocating_task
|
| 61 | - overcommit_kbytes
|
| 62 | - overcommit_memory
|
| 63 | - overcommit_ratio
|
| 64 | - page-cluster
|
| 65 | - page_lock_unfairness
|
| 66 | - panic_on_oom
|
| 67 | - panic_on_unrecoverable_memory_failure
|
| 68 | - percpu_pagelist_high_fraction
|
| 69 | - stat_interval
|
| 70 | - stat_refresh
|
| 71 | - numa_stat
|
| 72 | - swappiness
|
| 73 | - unprivileged_userfaultfd
|
| 74 | - user_reserve_kbytes
|
| 75 | - vfs_cache_pressure
|
| 76 | - vfs_cache_pressure_denom
|
| 77 | - watermark_boost_factor
|
| 78 | - watermark_scale_factor
|
| 79 | - zone_reclaim_mode
|
| 80 |
|
| 81 |
|
| 82 | admin_reserve_kbytes
|
| 83 | ====================
|
| 84 |
|
| 85 | The amount of free memory in the system that should be reserved for users
|
| 86 | with the capability cap_sys_admin.
|
| 87 |
|
| 88 | admin_reserve_kbytes defaults to min(3% of free pages, 8MB)
|
| 89 |
|
| 90 | That should provide enough for the admin to log in and kill a process,
|
| 91 | if necessary, under the default overcommit 'guess' mode.
|
| 92 |
|
| 93 | Systems running under overcommit 'never' should increase this to account
|
| 94 | for the full Virtual Memory Size of programs used to recover. Otherwise,
|
| 95 | root may not be able to log in to recover the system.
|
| 96 |
|
| 97 | How do you calculate a minimum useful reserve?
|
| 98 |
|
| 99 | sshd or login + bash (or some other shell) + top (or ps, kill, etc.)
|
| 100 |
|
| 101 | For overcommit 'guess', we can sum resident set sizes (RSS).
|
| 102 | On x86_64 this is about 8MB.
|
| 103 |
|
| 104 | For overcommit 'never', we can take the max of their virtual sizes (VSZ)
|
| 105 | and add the sum of their RSS.
|
| 106 | On x86_64 this is about 128MB.
|
| 107 |
|
| 108 | Changing this takes effect whenever an application requests memory.
|
| 109 |
|
| 110 |
|
| 111 | compact_memory
|
| 112 | ==============
|
| 113 |
|
| 114 | Available only when CONFIG_COMPACTION is set. When 1 is written to the file,
|
| 115 | all zones are compacted such that free memory is available in contiguous
|
| 116 | blocks where possible. This can be important for example in the allocation of
|
| 117 | huge pages although processes will also directly compact memory as required.
|
| 118 |
|
| 119 | compaction_proactiveness
|
| 120 | ========================
|
| 121 |
|
| 122 | This tunable takes a value in the range [0, 100] with a default value of
|
| 123 | 20. This tunable determines how aggressively compaction is done in the
|
| 124 | background. Write of a non zero value to this tunable will immediately
|
| 125 | trigger the proactive compaction. Setting it to 0 disables proactive compaction.
|
| 126 |
|
| 127 | Note that compaction has a non-trivial system-wide impact as pages
|
| 128 | belonging to different processes are moved around, which could also lead
|
| 129 | to latency spikes in unsuspecting applications. The kernel employs
|
| 130 | various heuristics to avoid wasting CPU cycles if it detects that
|
| 131 | proactive compaction is not being effective.
|
| 132 |
|
| 133 | Setting the value above 80 will, in addition to lowering the acceptable level
|
| 134 | of fragmentation, make the compaction code more sensitive to increases in
|
| 135 | fragmentation, i.e. compaction will trigger more often, but reduce
|
| 136 | fragmentation by a smaller amount.
|
| 137 | This makes the fragmentation level more stable over time.
|
| 138 |
|
| 139 | Be careful when setting it to extreme values like 100, as that may
|
| 140 | cause excessive background compaction activity.
|
| 141 |
|
| 142 | compact_unevictable_allowed
|
| 143 | ===========================
|
| 144 |
|
| 145 | Available only when CONFIG_COMPACTION is set. When set to 1, compaction is
|
| 146 | allowed to examine the unevictable lru (mlocked pages) for pages to compact.
|
| 147 | This should be used on systems where stalls for minor page faults are an
|
| 148 | acceptable trade for large contiguous free memory. Set to 0 to prevent
|
| 149 | compaction from moving pages that are unevictable. Default value is 1.
|
| 150 | On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due
|
| 151 | to compaction, which would block the task from becoming active until the fault
|
| 152 | is resolved.
|
| 153 |
|
| 154 | defrag_mode
|
| 155 | ===========
|
| 156 |
|
| 157 | When set to 1, the page allocator tries harder to avoid fragmentation
|
| 158 | and maintain the ability to produce huge pages / higher-order pages.
|
| 159 |
|
| 160 | It is recommended to enable this right after boot, as fragmentation,
|
| 161 | once it occurred, can be long-lasting or even permanent.
|
| 162 |
|
| 163 | dirty_background_bytes
|
| 164 | ======================
|
| 165 |
|
| 166 | Contains the amount of dirty memory at which the background kernel
|
| 167 | flusher threads will start writeback.
|
| 168 |
|
| 169 | Note:
|
| 170 | dirty_background_bytes is the counterpart of dirty_background_ratio. Only
|
| 171 | one of them may be specified at a time. When one sysctl is written it is
|
| 172 | immediately taken into account to evaluate the dirty memory limits and the
|
| 173 | other appears as 0 when read.
|
| 174 |
|
| 175 |
|
| 176 | dirty_background_ratio
|
| 177 | ======================
|
| 178 |
|
| 179 | Contains, as a percentage of total available memory that contains free pages
|
| 180 | and reclaimable pages, the number of pages at which the background kernel
|
| 181 | flusher threads will start writing out dirty data.
|
| 182 |
|
| 183 | The total available memory is not equal to total system memory.
|
| 184 |
|
| 185 |
|
| 186 | dirty_bytes
|
| 187 | ===========
|
| 188 |
|
| 189 | Contains the amount of dirty memory at which a process generating disk writes
|
| 190 | will itself start writeback.
|
| 191 |
|
| 192 | Note: dirty_bytes is the counterpart of dirty_ratio. Only one of them may be
|
| 193 | specified at a time. When one sysctl is written it is immediately taken into
|
| 194 | account to evaluate the dirty memory limits and the other appears as 0 when
|
| 195 | read.
|
| 196 |
|
| 197 | Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any
|
| 198 | value lower than this limit will be ignored and the old configuration will be
|
| 199 | retained.
|
| 200 |
|
| 201 |
|
| 202 | dirty_expire_centisecs
|
| 203 | ======================
|
| 204 |
|
| 205 | This tunable is used to define when dirty data is old enough to be eligible
|
| 206 | for writeout by the kernel flusher threads. It is expressed in 100'ths
|
| 207 | of a second. Data which has been dirty in-memory for longer than this
|
| 208 | interval will be written out next time a flusher thread wakes up.
|
| 209 |
|
| 210 |
|
| 211 | dirty_ratio
|
| 212 | ===========
|
| 213 |
|
| 214 | Contains, as a percentage of total available memory that contains free pages
|
| 215 | and reclaimable pages, the number of pages at which a process which is
|
| 216 | generating disk writes will itself start writing out dirty data.
|
| 217 |
|
| 218 | The total available memory is not equal to total system memory.
|
| 219 |
|
| 220 |
|
| 221 | dirtytime_expire_seconds
|
| 222 | ========================
|
| 223 |
|
| 224 | When a lazytime inode is constantly having its pages dirtied, the inode with
|
| 225 | an updated timestamp will never get chance to be written out. And, if the
|
| 226 | only thing that has happened on the file system is a dirtytime inode caused
|
| 227 | by an atime update, a worker will be scheduled to make sure that inode
|
| 228 | eventually gets pushed out to disk. This tunable is used to define when dirty
|
| 229 | inode is old enough to be eligible for writeback by the kernel flusher threads.
|
| 230 | And, it is also used as the interval to wakeup dirtytime_writeback thread.
|
| 231 |
|
| 232 | Setting this to zero disables periodic dirtytime writeback.
|
| 233 |
|
| 234 |
|
| 235 | dirty_writeback_centisecs
|
| 236 | =========================
|
| 237 |
|
| 238 | The kernel flusher threads will periodically wake up and write `old` data
|
| 239 | out to disk. This tunable expresses the interval between those wakeups, in
|
| 240 | 100'ths of a second.
|
| 241 |
|
| 242 | Setting this to zero disables periodic writeback altogether.
|
| 243 |
|
| 244 |
|
| 245 | drop_caches
|
| 246 | ===========
|
| 247 |
|
| 248 | Writing to this will cause the kernel to drop clean caches, as well as
|
| 249 | reclaimable slab objects like dentries and inodes. Once dropped, their
|
| 250 | memory becomes free.
|
| 251 |
|
| 252 | To free pagecache::
|
| 253 |
|
| 254 | echo 1 > /proc/sys/vm/drop_caches
|
| 255 |
|
| 256 | To free reclaimable slab objects (includes dentries and inodes)::
|
| 257 |
|
| 258 | echo 2 > /proc/sys/vm/drop_caches
|
| 259 |
|
| 260 | To free slab objects and pagecache::
|
| 261 |
|
| 262 | echo 3 > /proc/sys/vm/drop_caches
|
| 263 |
|
| 264 | This is a non-destructive operation and will not free any dirty objects.
|
| 265 | To increase the number of objects freed by this operation, the user may run
|
| 266 | `sync` prior to writing to /proc/sys/vm/drop_caches. This will minimize the
|
| 267 | number of dirty objects on the system and create more candidates to be
|
| 268 | dropped.
|
| 269 |
|
| 270 | This file is not a means to control the growth of the various kernel caches
|
| 271 | (inodes, dentries, pagecache, etc...) These objects are automatically
|
| 272 | reclaimed by the kernel when memory is needed elsewhere on the system.
|
| 273 |
|
| 274 | Use of this file can cause performance problems. Since it discards cached
|
| 275 | objects, it may cost a significant amount of I/O and CPU to recreate the
|
| 276 | dropped objects, especially if they were under heavy use. Because of this,
|
| 277 | use outside of a testing or debugging environment is not recommended.
|
| 278 |
|
| 279 | You may see informational messages in your kernel log when this file is
|
| 280 | used::
|
| 281 |
|
| 282 | cat (1234): drop_caches: 3
|
| 283 |
|
| 284 | These are informational only. They do not mean that anything is wrong
|
| 285 | with your system. To disable them, echo 4 (bit 2) into drop_caches.
|
| 286 |
|
| 287 | enable_soft_offline
|
| 288 | ===================
|
| 289 | Correctable memory errors are very common on servers. Soft-offline is kernel's
|
| 290 | solution for memory pages having (excessive) corrected memory errors.
|
| 291 |
|
| 292 | For different types of page, soft-offline has different behaviors / costs.
|
| 293 |
|
| 294 | - For a raw error page, soft-offline migrates the in-use page's content to
|
| 295 | a new raw page.
|
| 296 |
|
| 297 | - For a page that is part of a transparent hugepage, soft-offline splits the
|
| 298 | transparent hugepage into raw pages, then migrates only the raw error page.
|
| 299 | As a result, user is transparently backed by 1 less hugepage, impacting
|
| 300 | memory access performance.
|
| 301 |
|
| 302 | - For a page that is part of a HugeTLB hugepage, soft-offline first migrates
|
| 303 | the entire HugeTLB hugepage, during which a free hugepage will be consumed
|
| 304 | as migration target. Then the original hugepage is dissolved into raw
|
| 305 | pages without compensation, reducing the capacity of the HugeTLB pool by 1.
|
| 306 |
|
| 307 | It is user's call to choose between reliability (staying away from fragile
|
| 308 | physical memory) vs performance / capacity implications in transparent and
|
| 309 | HugeTLB cases.
|
| 310 |
|
| 311 | For all architectures, enable_soft_offline controls whether to soft offline
|
| 312 | memory pages. When set to 1, kernel attempts to soft offline the pages
|
| 313 | whenever it thinks needed. When set to 0, kernel returns EOPNOTSUPP to
|
| 314 | the request to soft offline the pages. Its default value is 1.
|
| 315 |
|
| 316 | It is worth mentioning that after setting enable_soft_offline to 0, the
|
| 317 | following requests to soft offline pages will not be performed:
|
| 318 |
|
| 319 | - Request to soft offline pages from RAS Correctable Errors Collector.
|
| 320 |
|
| 321 | - On ARM, the request to soft offline pages from GHES driver.
|
| 322 |
|
| 323 | - On PARISC, the request to soft offline pages from Page Deallocation Table.
|
| 324 |
|
| 325 | extfrag_threshold
|
| 326 | =================
|
| 327 |
|
| 328 | This parameter affects whether the kernel will compact memory or direct
|
| 329 | reclaim to satisfy a high-order allocation. The extfrag/extfrag_index file in
|
| 330 | debugfs shows what the fragmentation index for each order is in each zone in
|
| 331 | the system. Values tending towards 0 imply allocations would fail due to lack
|
| 332 | of memory, values towards 1000 imply failures are due to fragmentation and -1
|
| 333 | implies that the allocation will succeed as long as watermarks are met.
|
| 334 |
|
| 335 | The kernel will not compact memory in a zone if the
|
| 336 | fragmentation index is <= extfrag_threshold. The default value is 500.
|
| 337 |
|
| 338 |
|
| 339 | highmem_is_dirtyable
|
| 340 | ====================
|
| 341 |
|
| 342 | Available only for systems with CONFIG_HIGHMEM enabled (32b systems).
|
| 343 |
|
| 344 | This parameter controls whether the high memory is considered for dirty
|
| 345 | writers throttling. This is not the case by default which means that
|
| 346 | only the amount of memory directly visible/usable by the kernel can
|
| 347 | be dirtied. As a result, on systems with a large amount of memory and
|
| 348 | lowmem basically depleted writers might be throttled too early and
|
| 349 | streaming writes can get very slow.
|
| 350 |
|
| 351 | Changing the value to non zero would allow more memory to be dirtied
|
| 352 | and thus allow writers to write more data which can be flushed to the
|
| 353 | storage more effectively. Note this also comes with a risk of pre-mature
|
| 354 | OOM killer because some writers (e.g. direct block device writes) can
|
| 355 | only use the low memory and they can fill it up with dirty data without
|
| 356 | any throttling.
|
| 357 |
|
| 358 |
|
| 359 | hugetlb_shm_group
|
| 360 | =================
|
| 361 |
|
| 362 | hugetlb_shm_group contains group id that is allowed to create SysV
|
| 363 | shared memory segment using hugetlb page.
|
| 364 |
|
| 365 |
|
| 366 | legacy_va_layout
|
| 367 | ================
|
| 368 |
|
| 369 | If non-zero, this sysctl disables the new 32-bit mmap layout - the kernel
|
| 370 | will use the legacy (2.4) layout for all processes.
|
| 371 |
|
| 372 |
|
| 373 | lowmem_reserve_ratio
|
| 374 | ====================
|
| 375 |
|
| 376 | For some specialised workloads on highmem machines it is dangerous for
|
| 377 | the kernel to allow process memory to be allocated from the "lowmem"
|
| 378 | zone. This is because that memory could then be pinned via the mlock()
|
| 379 | system call, or by unavailability of swapspace.
|
| 380 |
|
| 381 | And on large highmem machines this lack of reclaimable lowmem memory
|
| 382 | can be fatal.
|
| 383 |
|
| 384 | So the Linux page allocator has a mechanism which prevents allocations
|
| 385 | which *could* use highmem from using too much lowmem. This means that
|
| 386 | a certain amount of lowmem is defended from the possibility of being
|
| 387 | captured into pinned user memory.
|
| 388 |
|
| 389 | (The same argument applies to the old 16 megabyte ISA DMA region. This
|
| 390 | mechanism will also defend that region from allocations which could use
|
| 391 | highmem or lowmem).
|
| 392 |
|
| 393 | The `lowmem_reserve_ratio` tunable determines how aggressive the kernel is
|
| 394 | in defending these lower zones.
|
| 395 |
|
| 396 | If you have a machine which uses highmem or ISA DMA and your
|
| 397 | applications are using mlock(), or if you are running with no swap then
|
| 398 | you probably should change the lowmem_reserve_ratio setting.
|
| 399 |
|
| 400 | The lowmem_reserve_ratio is an array. You can see them by reading this file::
|
| 401 |
|
| 402 | % cat /proc/sys/vm/lowmem_reserve_ratio
|
| 403 | 256 256 32
|
| 404 |
|
| 405 | But, these values are not used directly. The kernel calculates # of protection
|
| 406 | pages for each zones from them. These are shown as array of protection pages
|
| 407 | in /proc/zoneinfo like the following. (This is an example of x86-64 box).
|
| 408 | Each zone has an array of protection pages like this::
|
| 409 |
|
| 410 | Node 0, zone DMA
|
| 411 | pages free 1355
|
| 412 | min 3
|
| 413 | low 3
|
| 414 | high 4
|
| 415 | :
|
| 416 | :
|
| 417 | numa_other 0
|
| 418 | protection: (0, 2004, 2004, 2004)
|
| 419 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| 420 | pagesets
|
| 421 | cpu: 0 pcp: 0
|
| 422 | :
|
| 423 |
|
| 424 | These protections are added to score to judge whether this zone should be used
|
| 425 | for page allocation or should be reclaimed.
|
| 426 |
|
| 427 | In this example, if normal pages (index=2) are required to this DMA zone and
|
| 428 | watermark[WMARK_HIGH] is used for watermark, the kernel judges this zone should
|
| 429 | not be used because pages_free(1355) is smaller than watermark + protection[2]
|
| 430 | (4 + 2004 = 2008). If this protection value is 0, this zone would be used for
|
| 431 | normal page requirement. If requirement is DMA zone(index=0), protection[0]
|
| 432 | (=0) is used.
|
| 433 |
|
| 434 | zone[i]'s protection[j] is calculated by following expression::
|
| 435 |
|
| 436 | (i < j):
|
| 437 | zone[i]->protection[j]
|
| 438 | = (total sums of managed_pages from zone[i+1] to zone[j] on the node)
|
| 439 | / lowmem_reserve_ratio[i];
|
| 440 | (i = j):
|
| 441 | (should not be protected. = 0)
|
| 442 | (i > j):
|
| 443 | (not necessary, but looks 0)
|
| 444 |
|
| 445 | The default values of lowmem_reserve_ratio[i] are
|
| 446 |
|
| 447 | === ====================================
|
| 448 | 256 (if zone[i] means DMA or DMA32 zone)
|
| 449 | 32 (others)
|
| 450 | === ====================================
|
| 451 |
|
| 452 | As above expression, they are reciprocal number of ratio.
|
| 453 | 256 means 1/256. # of protection pages becomes about "0.39%" of total managed
|
| 454 | pages of higher zones on the node.
|
| 455 |
|
| 456 | If you would like to protect more pages, smaller values are effective.
|
| 457 | The minimum value is 1 (1/1 -> 100%). The value less than 1 completely
|
| 458 | disables protection of the pages.
|
| 459 |
|
| 460 |
|
| 461 | max_map_count
|
| 462 | =============
|
| 463 |
|
| 464 | This file contains the maximum number of memory map areas a process
|
| 465 | may have. Memory map areas are used as a side-effect of calling
|
| 466 | malloc, directly by mmap, mprotect, and madvise, and also when loading
|
| 467 | shared libraries.
|
| 468 |
|
| 469 | While most applications need less than a thousand maps, certain
|
| 470 | programs, particularly malloc debuggers, may consume lots of them,
|
| 471 | e.g., up to one or two maps per allocation.
|
| 472 |
|
| 473 | The default value is 65530.
|
| 474 |
|
| 475 |
|
| 476 | mem_profiling
|
| 477 | ==============
|
| 478 |
|
| 479 | Enable memory profiling (when CONFIG_MEM_ALLOC_PROFILING=y)
|
| 480 |
|
| 481 | 1: Enable memory profiling.
|
| 482 |
|
| 483 | 0: Disable memory profiling.
|
| 484 |
|
| 485 | Enabling memory profiling introduces a small performance overhead for all
|
| 486 | memory allocations.
|
| 487 |
|
| 488 | The default value depends on CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT.
|
| 489 |
|
| 490 | When CONFIG_MEM_ALLOC_PROFILING_DEBUG=y, this control is read-only to avoid
|
| 491 | warnings produced by allocations made while profiling is disabled and freed
|
| 492 | when it's enabled.
|
| 493 |
|
| 494 |
|
| 495 | memory_failure_early_kill
|
| 496 | =========================
|
| 497 |
|
| 498 | Control how to kill processes when uncorrected memory error (typically
|
| 499 | a 2bit error in a memory module) is detected in the background by hardware
|
| 500 | that cannot be handled by the kernel. In some cases (like the page
|
| 501 | still having a valid copy on disk) the kernel will handle the failure
|
| 502 | transparently without affecting any applications. But if there is
|
| 503 | no other up-to-date copy of the data it will kill to prevent any data
|
| 504 | corruptions from propagating.
|
| 505 |
|
| 506 | 1: Kill all processes that have the corrupted and not reloadable page mapped
|
| 507 | as soon as the corruption is detected. Note this is not supported
|
| 508 | for a few types of pages, like kernel internally allocated data or
|
| 509 | the swap cache, but works for the majority of user pages.
|
| 510 |
|
| 511 | 0: Only unmap the corrupted page from all processes and only kill a process
|
| 512 | who tries to access it.
|
| 513 |
|
| 514 | The kill is done using a catchable SIGBUS with BUS_MCEERR_AO, so processes can
|
| 515 | handle this if they want to.
|
| 516 |
|
| 517 | This is only active on architectures/platforms with advanced machine
|
| 518 | check handling and depends on the hardware capabilities.
|
| 519 |
|
| 520 | Applications can override this setting individually with the PR_MCE_KILL prctl
|
| 521 |
|
| 522 |
|
| 523 | memory_failure_recovery
|
| 524 | =======================
|
| 525 |
|
| 526 | Enable memory failure recovery (when supported by the platform)
|
| 527 |
|
| 528 | 1: Attempt recovery.
|
| 529 |
|
| 530 | 0: Always panic on a memory failure.
|
| 531 |
|
| 532 |
|
| 533 | min_free_kbytes
|
| 534 | ===============
|
| 535 |
|
| 536 | This is used to force the Linux VM to keep a minimum number
|
| 537 | of kilobytes free. The VM uses this number to compute a
|
| 538 | watermark[WMARK_MIN] value for each lowmem zone in the system.
|
| 539 | Each lowmem zone gets a number of reserved free pages based
|
| 540 | proportionally on its size.
|
| 541 |
|
| 542 | Some minimal amount of memory is needed to satisfy PF_MEMALLOC
|
| 543 | allocations; if you set this to lower than 1024KB, your system will
|
| 544 | become subtly broken, and prone to deadlock under high loads.
|
| 545 |
|
| 546 | Setting this too high will OOM your machine instantly.
|
| 547 |
|
| 548 |
|
| 549 | min_slab_ratio
|
| 550 | ==============
|
| 551 |
|
| 552 | This is available only on NUMA kernels.
|
| 553 |
|
| 554 | A percentage of the total pages in each zone. On Zone reclaim
|
| 555 | (fallback from the local zone occurs) slabs will be reclaimed if more
|
| 556 | than this percentage of pages in a zone are reclaimable slab pages.
|
| 557 | This insures that the slab growth stays under control even in NUMA
|
| 558 | systems that rarely perform global reclaim.
|
| 559 |
|
| 560 | The default is 5 percent.
|
| 561 |
|
| 562 | Note that slab reclaim is triggered in a per zone / node fashion.
|
| 563 | The process of reclaiming slab memory is currently not node specific
|
| 564 | and may not be fast.
|
| 565 |
|
| 566 |
|
| 567 | min_unmapped_ratio
|
| 568 | ==================
|
| 569 |
|
| 570 | This is available only on NUMA kernels.
|
| 571 |
|
| 572 | This is a percentage of the total pages in each zone. Zone reclaim will
|
| 573 | only occur if more than this percentage of pages are in a state that
|
| 574 | zone_reclaim_mode allows to be reclaimed.
|
| 575 |
|
| 576 | If zone_reclaim_mode has the value 4 OR'd, then the percentage is compared
|
| 577 | against all file-backed unmapped pages including swapcache pages and tmpfs
|
| 578 | files. Otherwise, only unmapped pages backed by normal files but not tmpfs
|
| 579 | files and similar are considered.
|
| 580 |
|
| 581 | The default is 1 percent.
|
| 582 |
|
| 583 |
|
| 584 | mmap_min_addr
|
| 585 | =============
|
| 586 |
|
| 587 | This file indicates the amount of address space which a user process will
|
| 588 | be restricted from mmapping. Since kernel null dereference bugs could
|
| 589 | accidentally operate based on the information in the first couple of pages
|
| 590 | of memory userspace processes should not be allowed to write to them. By
|
| 591 | default this value is set to 0 and no protections will be enforced by the
|
| 592 | security module. Setting this value to something like 64k will allow the
|
| 593 | vast majority of applications to work correctly and provide defense in depth
|
| 594 | against future potential kernel bugs.
|
| 595 |
|
| 596 |
|
| 597 | mmap_rnd_bits
|
| 598 | =============
|
| 599 |
|
| 600 | This value can be used to select the number of bits to use to
|
| 601 | determine the random offset to the base address of vma regions
|
| 602 | resulting from mmap allocations on architectures which support
|
| 603 | tuning address space randomization. This value will be bounded
|
| 604 | by the architecture's minimum and maximum supported values.
|
| 605 |
|
| 606 | This value can be changed after boot using the
|
| 607 | /proc/sys/vm/mmap_rnd_bits tunable
|
| 608 |
|
| 609 |
|
| 610 | mmap_rnd_compat_bits
|
| 611 | ====================
|
| 612 |
|
| 613 | This value can be used to select the number of bits to use to
|
| 614 | determine the random offset to the base address of vma regions
|
| 615 | resulting from mmap allocations for applications run in
|
| 616 | compatibility mode on architectures which support tuning address
|
| 617 | space randomization. This value will be bounded by the
|
| 618 | architecture's minimum and maximum supported values.
|
| 619 |
|
| 620 | This value can be changed after boot using the
|
| 621 | /proc/sys/vm/mmap_rnd_compat_bits tunable
|
| 622 |
|
| 623 |
|
| 624 | movable_gigantic_pages
|
| 625 | ======================
|
| 626 |
|
| 627 | This parameter controls whether gigantic pages may be allocated from
|
| 628 | ZONE_MOVABLE. If set to non-zero, gigantic pages can be allocated
|
| 629 | from ZONE_MOVABLE. ZONE_MOVABLE memory may be created via the kernel
|
| 630 | boot parameter `kernelcore` or via memory hotplug as discussed in
|
| 631 | Documentation/admin-guide/mm/memory-hotplug.rst.
|
| 632 |
|
| 633 | Support may depend on specific architecture.
|
| 634 |
|
| 635 | Note that using ZONE_MOVABLE gigantic pages make memory hotremove unreliable.
|
| 636 |
|
| 637 | Memory hot-remove operations will block indefinitely until the admin reserves
|
| 638 | sufficient gigantic pages to service migration requests associated with the
|
| 639 | memory offlining process. As HugeTLB gigantic page reservation is a manual
|
| 640 | process (via `nodeN/hugepages/.../nr_hugepages` interfaces) this may not be
|
| 641 | obvious when just attempting to offline a block of memory.
|
| 642 |
|
| 643 | Additionally, as multiple gigantic pages may be reserved on a single block,
|
| 644 | it may appear that gigantic pages are available for migration when in reality
|
| 645 | they are in the process of being removed. For example if `memoryN` contains
|
| 646 | two gigantic pages, one reserved and one allocated, and an admin attempts to
|
| 647 | offline that block, this operations may hang indefinitely unless another
|
| 648 | reserved gigantic page is available on another block `memoryM`.
|
| 649 |
|
| 650 |
|
| 651 | nr_hugepages
|
| 652 | ============
|
| 653 |
|
| 654 | Change the minimum size of the hugepage pool.
|
| 655 |
|
| 656 | See Documentation/admin-guide/mm/hugetlbpage.rst
|
| 657 |
|
| 658 |
|
| 659 | hugetlb_optimize_vmemmap
|
| 660 | ========================
|
| 661 |
|
| 662 | This knob is not available when the size of 'struct page' (a structure defined
|
| 663 | in include/linux/mm_types.h) is not power of two (an unusual system config could
|
| 664 | result in this).
|
| 665 |
|
| 666 | Enable (set to 1) or disable (set to 0) HugeTLB Vmemmap Optimization (HVO).
|
| 667 |
|
| 668 | Once enabled, the vmemmap pages of subsequent allocation of HugeTLB pages from
|
| 669 | buddy allocator will be optimized (7 pages per 2MB HugeTLB page and 4095 pages
|
| 670 | per 1GB HugeTLB page), whereas already allocated HugeTLB pages will not be
|
| 671 | optimized. When those optimized HugeTLB pages are freed from the HugeTLB pool
|
| 672 | to the buddy allocator, the vmemmap pages representing that range needs to be
|
| 673 | remapped again and the vmemmap pages discarded earlier need to be rellocated
|
| 674 | again. If your use case is that HugeTLB pages are allocated 'on the fly' (e.g.
|
| 675 | never explicitly allocating HugeTLB pages with 'nr_hugepages' but only set
|
| 676 | 'nr_overcommit_hugepages', those overcommitted HugeTLB pages are allocated 'on
|
| 677 | the fly') instead of being pulled from the HugeTLB pool, you should weigh the
|
| 678 | benefits of memory savings against the more overhead (~2x slower than before)
|
| 679 | of allocation or freeing HugeTLB pages between the HugeTLB pool and the buddy
|
| 680 | allocator. Another behavior to note is that if the system is under heavy memory
|
| 681 | pressure, it could prevent the user from freeing HugeTLB pages from the HugeTLB
|
| 682 | pool to the buddy allocator since the allocation of vmemmap pages could be
|
| 683 | failed, you have to retry later if your system encounter this situation.
|
| 684 |
|
| 685 | Once disabled, the vmemmap pages of subsequent allocation of HugeTLB pages from
|
| 686 | buddy allocator will not be optimized meaning the extra overhead at allocation
|
| 687 | time from buddy allocator disappears, whereas already optimized HugeTLB pages
|
| 688 | will not be affected. If you want to make sure there are no optimized HugeTLB
|
| 689 | pages, you can set "nr_hugepages" to 0 first and then disable this. Note that
|
| 690 | writing 0 to nr_hugepages will make any "in use" HugeTLB pages become surplus
|
| 691 | pages. So, those surplus pages are still optimized until they are no longer
|
| 692 | in use. You would need to wait for those surplus pages to be released before
|
| 693 | there are no optimized pages in the system.
|
| 694 |
|
| 695 |
|
| 696 | nr_hugepages_mempolicy
|
| 697 | ======================
|
| 698 |
|
| 699 | Change the size of the hugepage pool at run-time on a specific
|
| 700 | set of NUMA nodes.
|
| 701 |
|
| 702 | See Documentation/admin-guide/mm/hugetlbpage.rst
|
| 703 |
|
| 704 |
|
| 705 | nr_overcommit_hugepages
|
| 706 | =======================
|
| 707 |
|
| 708 | Change the maximum size of the hugepage pool. The maximum is
|
| 709 | nr_hugepages + nr_overcommit_hugepages.
|
| 710 |
|
| 711 | See Documentation/admin-guide/mm/hugetlbpage.rst
|
| 712 |
|
| 713 |
|
| 714 | nr_trim_pages
|
| 715 | =============
|
| 716 |
|
| 717 | This is available only on NOMMU kernels.
|
| 718 |
|
| 719 | This value adjusts the excess page trimming behaviour of power-of-2 aligned
|
| 720 | NOMMU mmap allocations.
|
| 721 |
|
| 722 | A value of 0 disables trimming of allocations entirely, while a value of 1
|
| 723 | trims excess pages aggressively. Any value >= 1 acts as the watermark where
|
| 724 | trimming of allocations is initiated.
|
| 725 |
|
| 726 | The default value is 1.
|
| 727 |
|
| 728 | See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
|
| 729 |
|
| 730 |
|
| 731 | numa_zonelist_order
|
| 732 | ===================
|
| 733 |
|
| 734 | This sysctl is only for NUMA and it is deprecated. Anything but
|
| 735 | Node order will fail!
|
| 736 |
|
| 737 | 'where the memory is allocated from' is controlled by zonelists.
|
| 738 |
|
| 739 | (This documentation ignores ZONE_HIGHMEM/ZONE_DMA32 for simple explanation.
|
| 740 | you may be able to read ZONE_DMA as ZONE_DMA32...)
|
| 741 |
|
| 742 | In non-NUMA case, a zonelist for GFP_KERNEL is ordered as following.
|
| 743 | ZONE_NORMAL -> ZONE_DMA
|
| 744 | This means that a memory allocation request for GFP_KERNEL will
|
| 745 | get memory from ZONE_DMA only when ZONE_NORMAL is not available.
|
| 746 |
|
| 747 | In NUMA case, you can think of following 2 types of order.
|
| 748 | Assume 2 node NUMA and below is zonelist of Node(0)'s GFP_KERNEL::
|
| 749 |
|
| 750 | (A) Node(0) ZONE_NORMAL -> Node(0) ZONE_DMA -> Node(1) ZONE_NORMAL
|
| 751 | (B) Node(0) ZONE_NORMAL -> Node(1) ZONE_NORMAL -> Node(0) ZONE_DMA.
|
| 752 |
|
| 753 | Type(A) offers the best locality for processes on Node(0), but ZONE_DMA
|
| 754 | will be used before ZONE_NORMAL exhaustion. This increases possibility of
|
| 755 | out-of-memory(OOM) of ZONE_DMA because ZONE_DMA is tend to be small.
|
| 756 |
|
| 757 | Type(B) cannot offer the best locality but is more robust against OOM of
|
| 758 | the DMA zone.
|
| 759 |
|
| 760 | Type(A) is called as "Node" order. Type (B) is "Zone" order.
|
| 761 |
|
| 762 | "Node order" orders the zonelists by node, then by zone within each node.
|
| 763 | Specify "[Nn]ode" for node order
|
| 764 |
|
| 765 | "Zone Order" orders the zonelists by zone type, then by node within each
|
| 766 | zone. Specify "[Zz]one" for zone order.
|
| 767 |
|
| 768 | Specify "[Dd]efault" to request automatic configuration.
|
| 769 |
|
| 770 | On 32-bit, the Normal zone needs to be preserved for allocations accessible
|
| 771 | by the kernel, so "zone" order will be selected.
|
| 772 |
|
| 773 | On 64-bit, devices that require DMA32/DMA are relatively rare, so "node"
|
| 774 | order will be selected.
|
| 775 |
|
| 776 | Default order is recommended unless this is causing problems for your
|
| 777 | system/application.
|
| 778 |
|
| 779 |
|
| 780 | oom_dump_tasks
|
| 781 | ==============
|
| 782 |
|
| 783 | Enables a system-wide task dump (excluding kernel threads) to be produced
|
| 784 | when the kernel performs an OOM-killing and includes such information as
|
| 785 | pid, uid, tgid, vm size, rss, pgtables_bytes, swapents, oom_score_adj
|
| 786 | score, and name. This is helpful to determine why the OOM killer was
|
| 787 | invoked, to identify the rogue task that caused it, and to determine why
|
| 788 | the OOM killer chose the task it did to kill.
|
| 789 |
|
| 790 | If this is set to zero, this information is suppressed. On very
|
| 791 | large systems with thousands of tasks it may not be feasible to dump
|
| 792 | the memory state information for each one. Such systems should not
|
| 793 | be forced to incur a performance penalty in OOM conditions when the
|
| 794 | information may not be desired.
|
| 795 |
|
| 796 | If this is set to non-zero, this information is shown whenever the
|
| 797 | OOM killer actually kills a memory-hogging task.
|
| 798 |
|
| 799 | The default value is 1 (enabled).
|
| 800 |
|
| 801 |
|
| 802 | oom_kill_allocating_task
|
| 803 | ========================
|
| 804 |
|
| 805 | This enables or disables killing the OOM-triggering task in
|
| 806 | out-of-memory situations.
|
| 807 |
|
| 808 | If this is set to zero, the OOM killer will scan through the entire
|
| 809 | tasklist and select a task based on heuristics to kill. This normally
|
| 810 | selects a rogue memory-hogging task that frees up a large amount of
|
| 811 | memory when killed.
|
| 812 |
|
| 813 | If this is set to non-zero, the OOM killer simply kills the task that
|
| 814 | triggered the out-of-memory condition. This avoids the expensive
|
| 815 | tasklist scan.
|
| 816 |
|
| 817 | If panic_on_oom is selected, it takes precedence over whatever value
|
| 818 | is used in oom_kill_allocating_task.
|
| 819 |
|
| 820 | The default value is 0.
|
| 821 |
|
| 822 |
|
| 823 | overcommit_kbytes
|
| 824 | =================
|
| 825 |
|
| 826 | When overcommit_memory is set to 2, the committed address space is not
|
| 827 | permitted to exceed swap plus this amount of physical RAM. See below.
|
| 828 |
|
| 829 | Note: overcommit_kbytes is the counterpart of overcommit_ratio. Only one
|
| 830 | of them may be specified at a time. Setting one disables the other (which
|
| 831 | then appears as 0 when read).
|
| 832 |
|
| 833 |
|
| 834 | overcommit_memory
|
| 835 | =================
|
| 836 |
|
| 837 | This value contains a flag that enables memory overcommitment.
|
| 838 |
|
| 839 | When this flag is 0, the kernel compares the userspace memory request
|
| 840 | size against total memory plus swap and rejects obvious overcommits.
|
| 841 |
|
| 842 | When this flag is 1, the kernel pretends there is always enough
|
| 843 | memory until it actually runs out.
|
| 844 |
|
| 845 | When this flag is 2, the kernel uses a "never overcommit"
|
| 846 | policy that attempts to prevent any overcommit of memory.
|
| 847 | Note that user_reserve_kbytes affects this policy.
|
| 848 |
|
| 849 | This feature can be very useful because there are a lot of
|
| 850 | programs that malloc() huge amounts of memory "just-in-case"
|
| 851 | and don't use much of it.
|
| 852 |
|
| 853 | The default value is 0.
|
| 854 |
|
| 855 | See Documentation/mm/overcommit-accounting.rst and
|
| 856 | mm/util.c::__vm_enough_memory() for more information.
|
| 857 |
|
| 858 |
|
| 859 | overcommit_ratio
|
| 860 | ================
|
| 861 |
|
| 862 | When overcommit_memory is set to 2, the committed address
|
| 863 | space is not permitted to exceed swap plus this percentage
|
| 864 | of physical RAM. See above.
|
| 865 |
|
| 866 |
|
| 867 | page-cluster
|
| 868 | ============
|
| 869 |
|
| 870 | page-cluster controls the number of pages up to which consecutive pages
|
| 871 | are read in from swap in a single attempt. This is the swap counterpart
|
| 872 | to page cache readahead.
|
| 873 | The mentioned consecutivity is not in terms of virtual/physical addresses,
|
| 874 | but consecutive on swap space - that means they were swapped out together.
|
| 875 |
|
| 876 | It is a logarithmic value - setting it to zero means "1 page", setting
|
| 877 | it to 1 means "2 pages", setting it to 2 means "4 pages", etc.
|
| 878 | Zero disables swap readahead completely.
|
| 879 |
|
| 880 | The default value is three (eight pages at a time). There may be some
|
| 881 | small benefits in tuning this to a different value if your workload is
|
| 882 | swap-intensive.
|
| 883 |
|
| 884 | Lower values mean lower latencies for initial faults, but at the same time
|
| 885 | extra faults and I/O delays for following faults if they would have been part of
|
| 886 | that consecutive pages readahead would have brought in.
|
| 887 |
|
| 888 |
|
| 889 | page_lock_unfairness
|
| 890 | ====================
|
| 891 |
|
| 892 | This value determines the number of times that the page lock can be
|
| 893 | stolen from under a waiter. After the lock is stolen the number of times
|
| 894 | specified in this file (default is 5), the "fair lock handoff" semantics
|
| 895 | will apply, and the waiter will only be awakened if the lock can be taken.
|
| 896 |
|
| 897 | panic_on_oom
|
| 898 | ============
|
| 899 |
|
| 900 | This enables or disables panic on out-of-memory feature.
|
| 901 |
|
| 902 | If this is set to 0, the kernel will kill some rogue process,
|
| 903 | called oom_killer. Usually, oom_killer can kill rogue processes and
|
| 904 | system will survive.
|
| 905 |
|
| 906 | If this is set to 1, the kernel panics when out-of-memory happens.
|
| 907 | However, if a process limits using nodes by mempolicy/cpusets,
|
| 908 | and those nodes become memory exhaustion status, one process
|
| 909 | may be killed by oom-killer. No panic occurs in this case.
|
| 910 | Because other nodes' memory may be free. This means system total status
|
| 911 | may be not fatal yet.
|
| 912 |
|
| 913 | If this is set to 2, the kernel panics compulsorily even on the
|
| 914 | above-mentioned. Even oom happens under memory cgroup, the whole
|
| 915 | system panics.
|
| 916 |
|
| 917 | The default value is 0.
|
| 918 |
|
| 919 | 1 and 2 are for failover of clustering. Please select either
|
| 920 | according to your policy of failover.
|
| 921 |
|
| 922 | panic_on_oom=2+kdump gives you very strong tool to investigate
|
| 923 | why oom happens. You can get snapshot.
|
| 924 |
|
| 925 |
|
| 926 | panic_on_unrecoverable_memory_failure
|
| 927 | ======================================
|
| 928 |
|
| 929 | When a hardware memory error (e.g. multi-bit ECC) hits a kernel page
|
| 930 | that cannot be recovered by the memory failure handler, the default
|
| 931 | behaviour is to ignore the error and continue operation. This is
|
| 932 | dangerous because the corrupted data remains accessible to the kernel,
|
| 933 | risking silent data corruption or a delayed crash when the poisoned
|
| 934 | memory is next accessed.
|
| 935 |
|
| 936 | When enabled, this sysctl triggers a panic on memory failure events
|
| 937 | hitting kernel-owned pages that the handler cannot recover:
|
| 938 | ``PageReserved`` (firmware reservations, kernel image, vDSO, zero
|
| 939 | page, and similar memblock-reserved regions), ``PageSlab``,
|
| 940 | ``PageTable``, and ``PageLargeKmalloc``. These are owned by the
|
| 941 | kernel and the memory failure handler cannot reliably evict their
|
| 942 | contents.
|
| 943 |
|
| 944 | Other unrecoverable kernel-owned populations (vmalloc allocations,
|
| 945 | kernel stack pages, ...) are not currently covered because the
|
| 946 | handler has no page-type signal that distinguishes them from a
|
| 947 | userspace folio temporarily off the LRU during migration or
|
| 948 | compaction. Such pages still go through the standard
|
| 949 | MF_MSG_GET_HWPOISON path: ``PG_hwpoison`` is set on them and a
|
| 950 | delayed crash on the next access remains possible. Coverage may
|
| 951 | grow as the handler gains stronger kernel-ownership signals.
|
| 952 |
|
| 953 | Recoverable failure paths are also intentionally left out: in-flight
|
| 954 | buddy allocations and other transient races with the page allocator
|
| 955 | can reach the same diagnostic, and panicking on them would risk
|
| 956 | killing the box for a page destined for userspace where the standard
|
| 957 | SIGBUS recovery path applies. Pages whose state could not be
|
| 958 | classified at all are not covered either, since an unknown state is
|
| 959 | not a sound basis for a panic decision.
|
| 960 |
|
| 961 | For many environments it is preferable to panic immediately with a clean
|
| 962 | crash dump that captures the original error context, rather than to
|
| 963 | continue and face a random crash later whose cause is difficult to
|
| 964 | diagnose.
|
| 965 |
|
| 966 | Use cases
|
| 967 | ---------
|
| 968 |
|
| 969 | This option is most useful in environments where unattributed crashes
|
| 970 | are expensive to debug or where data integrity must take precedence
|
| 971 | over availability:
|
| 972 |
|
| 973 | * Large fleets, where multi-bit ECC errors on kernel pages are observed
|
| 974 | regularly and post-mortem analysis of an unrelated downstream crash
|
| 975 | (often seconds to minutes after the original error) consumes
|
| 976 | significant engineering effort.
|
| 977 |
|
| 978 | * Systems configured with kdump, where panicking at the moment of the
|
| 979 | hardware error produces a vmcore that still contains the faulting
|
| 980 | address, the affected page state, and the originating MCE/GHES
|
| 981 | record — context that is typically lost by the time a delayed crash
|
| 982 | occurs.
|
| 983 |
|
| 984 | * High-availability clusters that rely on fast, deterministic node
|
| 985 | failure for failover, and prefer an immediate panic over silent data
|
| 986 | corruption propagating to replicas or persistent storage.
|
| 987 |
|
| 988 | * Kernel and platform developers reproducing hwpoison issues with
|
| 989 | tools such as ``mce-inject`` or error-injection debugfs interfaces,
|
| 990 | where panicking on the unrecoverable path makes regressions
|
| 991 | immediately visible instead of surfacing as later, unrelated
|
| 992 | failures.
|
| 993 |
|
| 994 | = =====================================================================
|
| 995 | 0 Try to continue operation (default).
|
| 996 | 1 Panic immediately. If the ``panic`` sysctl is also non-zero then the
|
| 997 | machine will be rebooted.
|
| 998 | = =====================================================================
|
| 999 |
|
| 1000 | Example::
|
| 1001 |
|
| 1002 | echo 1 > /proc/sys/vm/panic_on_unrecoverable_memory_failure
|
| 1003 |
|
| 1004 |
|
| 1005 | percpu_pagelist_high_fraction
|
| 1006 | =============================
|
| 1007 |
|
| 1008 | This is the fraction of pages in each zone that are can be stored to
|
| 1009 | per-cpu page lists. It is an upper boundary that is divided depending
|
| 1010 | on the number of online CPUs. The min value for this is 8 which means
|
| 1011 | that we do not allow more than 1/8th of pages in each zone to be stored
|
| 1012 | on per-cpu page lists. This entry only changes the value of hot per-cpu
|
| 1013 | page lists. A user can specify a number like 100 to allocate 1/100th of
|
| 1014 | each zone between per-cpu lists.
|
| 1015 |
|
| 1016 | The batch value of each per-cpu page list remains the same regardless of
|
| 1017 | the value of the high fraction so allocation latencies are unaffected.
|
| 1018 |
|
| 1019 | The initial value is zero. Kernel uses this value to set the high pcp->high
|
| 1020 | mark based on the low watermark for the zone and the number of local
|
| 1021 | online CPUs. If the user writes '0' to this sysctl, it will revert to
|
| 1022 | this default behavior.
|
| 1023 |
|
| 1024 |
|
| 1025 | stat_interval
|
| 1026 | =============
|
| 1027 |
|
| 1028 | The time interval between which vm statistics are updated. The default
|
| 1029 | is 1 second.
|
| 1030 |
|
| 1031 |
|
| 1032 | stat_refresh
|
| 1033 | ============
|
| 1034 |
|
| 1035 | Any read or write (by root only) flushes all the per-cpu vm statistics
|
| 1036 | into their global totals, for more accurate reports when testing
|
| 1037 | e.g. cat /proc/sys/vm/stat_refresh /proc/meminfo
|
| 1038 |
|
| 1039 | As a side-effect, it also checks for negative totals (elsewhere reported
|
| 1040 | as 0) and "fails" with EINVAL if any are found, with a warning in dmesg.
|
| 1041 | (At time of writing, a few stats are known sometimes to be found negative,
|
| 1042 | with no ill effects: errors and warnings on these stats are suppressed.)
|
| 1043 |
|
| 1044 |
|
| 1045 | numa_stat
|
| 1046 | =========
|
| 1047 |
|
| 1048 | This interface allows runtime configuration of numa statistics.
|
| 1049 |
|
| 1050 | When page allocation performance becomes a bottleneck and you can tolerate
|
| 1051 | some possible tool breakage and decreased numa counter precision, you can
|
| 1052 | do::
|
| 1053 |
|
| 1054 | echo 0 > /proc/sys/vm/numa_stat
|
| 1055 |
|
| 1056 | When page allocation performance is not a bottleneck and you want all
|
| 1057 | tooling to work, you can do::
|
| 1058 |
|
| 1059 | echo 1 > /proc/sys/vm/numa_stat
|
| 1060 |
|
| 1061 |
|
| 1062 | swappiness
|
| 1063 | ==========
|
| 1064 |
|
| 1065 | This control is used to define the rough relative IO cost of swapping
|
| 1066 | and filesystem paging, as a value between 0 and 200. At 100, the VM
|
| 1067 | assumes equal IO cost and will thus apply memory pressure to the page
|
| 1068 | cache and swap-backed pages equally; lower values signify more
|
| 1069 | expensive swap IO, higher values indicates cheaper.
|
| 1070 |
|
| 1071 | Keep in mind that filesystem IO patterns under memory pressure tend to
|
| 1072 | be more efficient than swap's random IO. An optimal value will require
|
| 1073 | experimentation and will also be workload-dependent.
|
| 1074 |
|
| 1075 | The default value is 60.
|
| 1076 |
|
| 1077 | For in-memory swap, like zram or zswap, as well as hybrid setups that
|
| 1078 | have swap on faster devices than the filesystem, values beyond 100 can
|
| 1079 | be considered. For example, if the random IO against the swap device
|
| 1080 | is on average 2x faster than IO from the filesystem, swappiness should
|
| 1081 | be 133 (x + 2x = 200, 2x = 133.33).
|
| 1082 |
|
| 1083 | At 0, the kernel will not initiate swap until the amount of free and
|
| 1084 | file-backed pages is less than the high watermark in a zone.
|
| 1085 |
|
| 1086 |
|
| 1087 | unprivileged_userfaultfd
|
| 1088 | ========================
|
| 1089 |
|
| 1090 | This flag controls the mode in which unprivileged users can use the
|
| 1091 | userfaultfd system calls. Set this to 0 to restrict unprivileged users
|
| 1092 | to handle page faults in user mode only. In this case, users without
|
| 1093 | SYS_CAP_PTRACE must pass UFFD_USER_MODE_ONLY in order for userfaultfd to
|
| 1094 | succeed. Prohibiting use of userfaultfd for handling faults from kernel
|
| 1095 | mode may make certain vulnerabilities more difficult to exploit.
|
| 1096 |
|
| 1097 | Set this to 1 to allow unprivileged users to use the userfaultfd system
|
| 1098 | calls without any restrictions.
|
| 1099 |
|
| 1100 | The default value is 0.
|
| 1101 |
|
| 1102 | Another way to control permissions for userfaultfd is to use
|
| 1103 | /dev/userfaultfd instead of userfaultfd(2). See
|
| 1104 | Documentation/admin-guide/mm/userfaultfd.rst.
|
| 1105 |
|
| 1106 | user_reserve_kbytes
|
| 1107 | ===================
|
| 1108 |
|
| 1109 | When overcommit_memory is set to 2, "never overcommit" mode, reserve
|
| 1110 | min(3% of current process size, user_reserve_kbytes) of free memory.
|
| 1111 | This is intended to prevent a user from starting a single memory hogging
|
| 1112 | process, such that they cannot recover (kill the hog).
|
| 1113 |
|
| 1114 | This setting has no effect when overcommit_memory is set to 0 or 1.
|
| 1115 |
|
| 1116 | user_reserve_kbytes defaults to min(3% of the current process size, 128MB).
|
| 1117 |
|
| 1118 | If this is reduced to zero, then the user will be allowed to allocate
|
| 1119 | all free memory with a single process, minus admin_reserve_kbytes.
|
| 1120 | Any subsequent attempts to execute a command will result in
|
| 1121 | "fork: Cannot allocate memory".
|
| 1122 |
|
| 1123 | Changing this takes effect whenever an application requests memory.
|
| 1124 |
|
| 1125 |
|
| 1126 | vfs_cache_pressure
|
| 1127 | ==================
|
| 1128 |
|
| 1129 | This percentage value controls the tendency of the kernel to reclaim
|
| 1130 | the memory which is used for caching of directory and inode objects.
|
| 1131 |
|
| 1132 | At the default value of vfs_cache_pressure=vfs_cache_pressure_denom the kernel
|
| 1133 | will attempt to reclaim dentries and inodes at a "fair" rate with respect to
|
| 1134 | pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the
|
| 1135 | kernel to prefer to retain dentry and inode caches. When vfs_cache_pressure=0,
|
| 1136 | the kernel will never reclaim dentries and inodes due to memory pressure and
|
| 1137 | this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure
|
| 1138 | beyond vfs_cache_pressure_denom causes the kernel to prefer to reclaim dentries
|
| 1139 | and inodes.
|
| 1140 |
|
| 1141 | Increasing vfs_cache_pressure significantly beyond vfs_cache_pressure_denom may
|
| 1142 | have negative performance impact. Reclaim code needs to take various locks to
|
| 1143 | find freeable directory and inode objects. When vfs_cache_pressure equals
|
| 1144 | (10 * vfs_cache_pressure_denom), it will look for ten times more freeable
|
| 1145 | objects than there are.
|
| 1146 |
|
| 1147 | Note: This setting should always be used together with vfs_cache_pressure_denom.
|
| 1148 |
|
| 1149 | vfs_cache_pressure_denom
|
| 1150 | ========================
|
| 1151 |
|
| 1152 | Defaults to 100 (minimum allowed value). Requires corresponding
|
| 1153 | vfs_cache_pressure setting to take effect.
|
| 1154 |
|
| 1155 | watermark_boost_factor
|
| 1156 | ======================
|
| 1157 |
|
| 1158 | This factor controls the level of reclaim when memory is being fragmented.
|
| 1159 | It defines the percentage of the high watermark of a zone that will be
|
| 1160 | reclaimed if pages of different mobility are being mixed within pageblocks.
|
| 1161 | The intent is that compaction has less work to do in the future and to
|
| 1162 | increase the success rate of future high-order allocations such as SLUB
|
| 1163 | allocations, THP and hugetlbfs pages.
|
| 1164 |
|
| 1165 | To make it sensible with respect to the watermark_scale_factor
|
| 1166 | parameter, the unit is in fractions of 10,000. The default value of
|
| 1167 | 15,000 means that up to 150% of the high watermark will be reclaimed in the
|
| 1168 | event of a pageblock being mixed due to fragmentation. The level of reclaim
|
| 1169 | is determined by the number of fragmentation events that occurred in the
|
| 1170 | recent past. If this value is smaller than a pageblock then a pageblocks
|
| 1171 | worth of pages will be reclaimed (e.g. 2MB on 64-bit x86). A boost factor
|
| 1172 | of 0 will disable the feature.
|
| 1173 |
|
| 1174 |
|
| 1175 | watermark_scale_factor
|
| 1176 | ======================
|
| 1177 |
|
| 1178 | This factor controls the aggressiveness of kswapd. It defines the
|
| 1179 | amount of memory left in a node/system before kswapd is woken up and
|
| 1180 | how much memory needs to be free before kswapd goes back to sleep.
|
| 1181 |
|
| 1182 | The unit is in fractions of 10,000. The default value of 10 means the
|
| 1183 | distances between watermarks are 0.1% of the available memory in the
|
| 1184 | node/system. The maximum value is 3000, or 30% of memory.
|
| 1185 |
|
| 1186 | A high rate of threads entering direct reclaim (allocstall) or kswapd
|
| 1187 | going to sleep prematurely (kswapd_low_wmark_hit_quickly) can indicate
|
| 1188 | that the number of free pages kswapd maintains for latency reasons is
|
| 1189 | too small for the allocation bursts occurring in the system. This knob
|
| 1190 | can then be used to tune kswapd aggressiveness accordingly.
|
| 1191 |
|
| 1192 |
|
| 1193 | zone_reclaim_mode
|
| 1194 | =================
|
| 1195 |
|
| 1196 | Zone_reclaim_mode allows someone to set more or less aggressive approaches to
|
| 1197 | reclaim memory when a zone runs out of memory. If it is set to zero then no
|
| 1198 | zone reclaim occurs. Allocations will be satisfied from other zones / nodes
|
| 1199 | in the system.
|
| 1200 |
|
| 1201 | This is value OR'ed together of
|
| 1202 |
|
| 1203 | = ===================================
|
| 1204 | 1 Zone reclaim on
|
| 1205 | 2 Zone reclaim writes dirty pages out
|
| 1206 | 4 Zone reclaim swaps pages
|
| 1207 | = ===================================
|
| 1208 |
|
| 1209 | zone_reclaim_mode is disabled by default. For file servers or workloads
|
| 1210 | that benefit from having their data cached, zone_reclaim_mode should be
|
| 1211 | left disabled as the caching effect is likely to be more important than
|
| 1212 | data locality.
|
| 1213 |
|
| 1214 | Consider enabling one or more zone_reclaim mode bits if it's known that the
|
| 1215 | workload is partitioned such that each partition fits within a NUMA node
|
| 1216 | and that accessing remote memory would cause a measurable performance
|
| 1217 | reduction. The page allocator will take additional actions before
|
| 1218 | allocating off node pages.
|
| 1219 |
|
| 1220 | Allowing zone reclaim to write out pages stops processes that are
|
| 1221 | writing large amounts of data from dirtying pages on other nodes. Zone
|
| 1222 | reclaim will write out dirty pages if a zone fills up and so effectively
|
| 1223 | throttle the process. This may decrease the performance of a single process
|
| 1224 | since it cannot use all of system memory to buffer the outgoing writes
|
| 1225 | anymore but it preserve the memory on other nodes so that the performance
|
| 1226 | of other processes running on other nodes will not be affected.
|
| 1227 |
|
| 1228 | Allowing regular swap effectively restricts allocations to the local
|
| 1229 | node unless explicitly overridden by memory policies or cpuset
|
| 1230 | configurations.
|