1# SPDX-License-Identifier: GPL-2.0-only 2 3menu "Memory Management options" 4 5# 6# For some reason microblaze and nios2 hard code SWAP=n. Hopefully we can 7# add proper SWAP support to them, in which case this can be remove. 8# 9config ARCH_NO_SWAP 10 bool 11 12config ZPOOL 13 bool 14 15menuconfig SWAP 16 bool "Support for paging of anonymous memory (swap)" 17 depends on MMU && BLOCK && !ARCH_NO_SWAP 18 default y 19 help 20 This option allows you to choose whether you want to have support 21 for so called swap devices or swap files in your kernel that are 22 used to provide more virtual memory than the actual RAM present 23 in your computer. If unsure say Y. 24 25config ZSWAP 26 bool "Compressed cache for swap pages (EXPERIMENTAL)" 27 depends on SWAP 28 select FRONTSWAP 29 select CRYPTO 30 select ZPOOL 31 help 32 A lightweight compressed cache for swap pages. It takes 33 pages that are in the process of being swapped out and attempts to 34 compress them into a dynamically allocated RAM-based memory pool. 35 This can result in a significant I/O reduction on swap device and, 36 in the case where decompressing from RAM is faster than swap device 37 reads, can also improve workload performance. 38 39 This is marked experimental because it is a new feature (as of 40 v3.11) that interacts heavily with memory reclaim. While these 41 interactions don't cause any known issues on simple memory setups, 42 they have not be fully explored on the large set of potential 43 configurations and workloads that exist. 44 45config ZSWAP_DEFAULT_ON 46 bool "Enable the compressed cache for swap pages by default" 47 depends on ZSWAP 48 help 49 If selected, the compressed cache for swap pages will be enabled 50 at boot, otherwise it will be disabled. 51 52 The selection made here can be overridden by using the kernel 53 command line 'zswap.enabled=' option. 54 55choice 56 prompt "Default compressor" 57 depends on ZSWAP 58 default ZSWAP_COMPRESSOR_DEFAULT_LZO 59 help 60 Selects the default compression algorithm for the compressed cache 61 for swap pages. 62 63 For an overview what kind of performance can be expected from 64 a particular compression algorithm please refer to the benchmarks 65 available at the following LWN page: 66 https://lwn.net/Articles/751795/ 67 68 If in doubt, select 'LZO'. 69 70 The selection made here can be overridden by using the kernel 71 command line 'zswap.compressor=' option. 72 73config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE 74 bool "Deflate" 75 select CRYPTO_DEFLATE 76 help 77 Use the Deflate algorithm as the default compression algorithm. 78 79config ZSWAP_COMPRESSOR_DEFAULT_LZO 80 bool "LZO" 81 select CRYPTO_LZO 82 help 83 Use the LZO algorithm as the default compression algorithm. 84 85config ZSWAP_COMPRESSOR_DEFAULT_842 86 bool "842" 87 select CRYPTO_842 88 help 89 Use the 842 algorithm as the default compression algorithm. 90 91config ZSWAP_COMPRESSOR_DEFAULT_LZ4 92 bool "LZ4" 93 select CRYPTO_LZ4 94 help 95 Use the LZ4 algorithm as the default compression algorithm. 96 97config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC 98 bool "LZ4HC" 99 select CRYPTO_LZ4HC 100 help 101 Use the LZ4HC algorithm as the default compression algorithm. 102 103config ZSWAP_COMPRESSOR_DEFAULT_ZSTD 104 bool "zstd" 105 select CRYPTO_ZSTD 106 help 107 Use the zstd algorithm as the default compression algorithm. 108endchoice 109 110config ZSWAP_COMPRESSOR_DEFAULT 111 string 112 depends on ZSWAP 113 default "deflate" if ZSWAP_COMPRESSOR_DEFAULT_DEFLATE 114 default "lzo" if ZSWAP_COMPRESSOR_DEFAULT_LZO 115 default "842" if ZSWAP_COMPRESSOR_DEFAULT_842 116 default "lz4" if ZSWAP_COMPRESSOR_DEFAULT_LZ4 117 default "lz4hc" if ZSWAP_COMPRESSOR_DEFAULT_LZ4HC 118 default "zstd" if ZSWAP_COMPRESSOR_DEFAULT_ZSTD 119 default "" 120 121choice 122 prompt "Default allocator" 123 depends on ZSWAP 124 default ZSWAP_ZPOOL_DEFAULT_ZBUD 125 help 126 Selects the default allocator for the compressed cache for 127 swap pages. 128 The default is 'zbud' for compatibility, however please do 129 read the description of each of the allocators below before 130 making a right choice. 131 132 The selection made here can be overridden by using the kernel 133 command line 'zswap.zpool=' option. 134 135config ZSWAP_ZPOOL_DEFAULT_ZBUD 136 bool "zbud" 137 select ZBUD 138 help 139 Use the zbud allocator as the default allocator. 140 141config ZSWAP_ZPOOL_DEFAULT_Z3FOLD 142 bool "z3fold" 143 select Z3FOLD 144 help 145 Use the z3fold allocator as the default allocator. 146 147config ZSWAP_ZPOOL_DEFAULT_ZSMALLOC 148 bool "zsmalloc" 149 select ZSMALLOC 150 help 151 Use the zsmalloc allocator as the default allocator. 152endchoice 153 154config ZSWAP_ZPOOL_DEFAULT 155 string 156 depends on ZSWAP 157 default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD 158 default "z3fold" if ZSWAP_ZPOOL_DEFAULT_Z3FOLD 159 default "zsmalloc" if ZSWAP_ZPOOL_DEFAULT_ZSMALLOC 160 default "" 161 162config ZBUD 163 tristate "2:1 compression allocator (zbud)" 164 depends on ZSWAP 165 help 166 A special purpose allocator for storing compressed pages. 167 It is designed to store up to two compressed pages per physical 168 page. While this design limits storage density, it has simple and 169 deterministic reclaim properties that make it preferable to a higher 170 density approach when reclaim will be used. 171 172config Z3FOLD 173 tristate "3:1 compression allocator (z3fold)" 174 depends on ZSWAP 175 help 176 A special purpose allocator for storing compressed pages. 177 It is designed to store up to three compressed pages per physical 178 page. It is a ZBUD derivative so the simplicity and determinism are 179 still there. 180 181config ZSMALLOC 182 tristate 183 prompt "N:1 compression allocator (zsmalloc)" if ZSWAP 184 depends on MMU 185 help 186 zsmalloc is a slab-based memory allocator designed to store 187 pages of various compression levels efficiently. It achieves 188 the highest storage density with the least amount of fragmentation. 189 190config ZSMALLOC_STAT 191 bool "Export zsmalloc statistics" 192 depends on ZSMALLOC 193 select DEBUG_FS 194 help 195 This option enables code in the zsmalloc to collect various 196 statistics about what's happening in zsmalloc and exports that 197 information to userspace via debugfs. 198 If unsure, say N. 199 200menu "SLAB allocator options" 201 202choice 203 prompt "Choose SLAB allocator" 204 default SLUB 205 help 206 This option allows to select a slab allocator. 207 208config SLAB 209 bool "SLAB" 210 depends on !PREEMPT_RT 211 select HAVE_HARDENED_USERCOPY_ALLOCATOR 212 help 213 The regular slab allocator that is established and known to work 214 well in all environments. It organizes cache hot objects in 215 per cpu and per node queues. 216 217config SLUB 218 bool "SLUB (Unqueued Allocator)" 219 select HAVE_HARDENED_USERCOPY_ALLOCATOR 220 help 221 SLUB is a slab allocator that minimizes cache line usage 222 instead of managing queues of cached objects (SLAB approach). 223 Per cpu caching is realized using slabs of objects instead 224 of queues of objects. SLUB can use memory efficiently 225 and has enhanced diagnostics. SLUB is the default choice for 226 a slab allocator. 227 228config SLOB 229 depends on EXPERT 230 bool "SLOB (Simple Allocator)" 231 depends on !PREEMPT_RT 232 help 233 SLOB replaces the stock allocator with a drastically simpler 234 allocator. SLOB is generally more space efficient but 235 does not perform as well on large systems. 236 237endchoice 238 239config SLAB_MERGE_DEFAULT 240 bool "Allow slab caches to be merged" 241 default y 242 depends on SLAB || SLUB 243 help 244 For reduced kernel memory fragmentation, slab caches can be 245 merged when they share the same size and other characteristics. 246 This carries a risk of kernel heap overflows being able to 247 overwrite objects from merged caches (and more easily control 248 cache layout), which makes such heap attacks easier to exploit 249 by attackers. By keeping caches unmerged, these kinds of exploits 250 can usually only damage objects in the same cache. To disable 251 merging at runtime, "slab_nomerge" can be passed on the kernel 252 command line. 253 254config SLAB_FREELIST_RANDOM 255 bool "Randomize slab freelist" 256 depends on SLAB || SLUB 257 help 258 Randomizes the freelist order used on creating new pages. This 259 security feature reduces the predictability of the kernel slab 260 allocator against heap overflows. 261 262config SLAB_FREELIST_HARDENED 263 bool "Harden slab freelist metadata" 264 depends on SLAB || SLUB 265 help 266 Many kernel heap attacks try to target slab cache metadata and 267 other infrastructure. This options makes minor performance 268 sacrifices to harden the kernel slab allocator against common 269 freelist exploit methods. Some slab implementations have more 270 sanity-checking than others. This option is most effective with 271 CONFIG_SLUB. 272 273config SLUB_STATS 274 default n 275 bool "Enable SLUB performance statistics" 276 depends on SLUB && SYSFS 277 help 278 SLUB statistics are useful to debug SLUBs allocation behavior in 279 order find ways to optimize the allocator. This should never be 280 enabled for production use since keeping statistics slows down 281 the allocator by a few percentage points. The slabinfo command 282 supports the determination of the most active slabs to figure 283 out which slabs are relevant to a particular load. 284 Try running: slabinfo -DA 285 286config SLUB_CPU_PARTIAL 287 default y 288 depends on SLUB && SMP 289 bool "SLUB per cpu partial cache" 290 help 291 Per cpu partial caches accelerate objects allocation and freeing 292 that is local to a processor at the price of more indeterminism 293 in the latency of the free. On overflow these caches will be cleared 294 which requires the taking of locks that may cause latency spikes. 295 Typically one would choose no for a realtime system. 296 297endmenu # SLAB allocator options 298 299config SHUFFLE_PAGE_ALLOCATOR 300 bool "Page allocator randomization" 301 default SLAB_FREELIST_RANDOM && ACPI_NUMA 302 help 303 Randomization of the page allocator improves the average 304 utilization of a direct-mapped memory-side-cache. See section 305 5.2.27 Heterogeneous Memory Attribute Table (HMAT) in the ACPI 306 6.2a specification for an example of how a platform advertises 307 the presence of a memory-side-cache. There are also incidental 308 security benefits as it reduces the predictability of page 309 allocations to compliment SLAB_FREELIST_RANDOM, but the 310 default granularity of shuffling on the "MAX_ORDER - 1" i.e, 311 10th order of pages is selected based on cache utilization 312 benefits on x86. 313 314 While the randomization improves cache utilization it may 315 negatively impact workloads on platforms without a cache. For 316 this reason, by default, the randomization is enabled only 317 after runtime detection of a direct-mapped memory-side-cache. 318 Otherwise, the randomization may be force enabled with the 319 'page_alloc.shuffle' kernel command line parameter. 320 321 Say Y if unsure. 322 323config COMPAT_BRK 324 bool "Disable heap randomization" 325 default y 326 help 327 Randomizing heap placement makes heap exploits harder, but it 328 also breaks ancient binaries (including anything libc5 based). 329 This option changes the bootup default to heap randomization 330 disabled, and can be overridden at runtime by setting 331 /proc/sys/kernel/randomize_va_space to 2. 332 333 On non-ancient distros (post-2000 ones) N is usually a safe choice. 334 335config MMAP_ALLOW_UNINITIALIZED 336 bool "Allow mmapped anonymous memory to be uninitialized" 337 depends on EXPERT && !MMU 338 default n 339 help 340 Normally, and according to the Linux spec, anonymous memory obtained 341 from mmap() has its contents cleared before it is passed to 342 userspace. Enabling this config option allows you to request that 343 mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus 344 providing a huge performance boost. If this option is not enabled, 345 then the flag will be ignored. 346 347 This is taken advantage of by uClibc's malloc(), and also by 348 ELF-FDPIC binfmt's brk and stack allocator. 349 350 Because of the obvious security issues, this option should only be 351 enabled on embedded devices where you control what is run in 352 userspace. Since that isn't generally a problem on no-MMU systems, 353 it is normally safe to say Y here. 354 355 See Documentation/admin-guide/mm/nommu-mmap.rst for more information. 356 357config SELECT_MEMORY_MODEL 358 def_bool y 359 depends on ARCH_SELECT_MEMORY_MODEL 360 361choice 362 prompt "Memory model" 363 depends on SELECT_MEMORY_MODEL 364 default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT 365 default FLATMEM_MANUAL 366 help 367 This option allows you to change some of the ways that 368 Linux manages its memory internally. Most users will 369 only have one option here selected by the architecture 370 configuration. This is normal. 371 372config FLATMEM_MANUAL 373 bool "Flat Memory" 374 depends on !ARCH_SPARSEMEM_ENABLE || ARCH_FLATMEM_ENABLE 375 help 376 This option is best suited for non-NUMA systems with 377 flat address space. The FLATMEM is the most efficient 378 system in terms of performance and resource consumption 379 and it is the best option for smaller systems. 380 381 For systems that have holes in their physical address 382 spaces and for features like NUMA and memory hotplug, 383 choose "Sparse Memory". 384 385 If unsure, choose this option (Flat Memory) over any other. 386 387config SPARSEMEM_MANUAL 388 bool "Sparse Memory" 389 depends on ARCH_SPARSEMEM_ENABLE 390 help 391 This will be the only option for some systems, including 392 memory hot-plug systems. This is normal. 393 394 This option provides efficient support for systems with 395 holes is their physical address space and allows memory 396 hot-plug and hot-remove. 397 398 If unsure, choose "Flat Memory" over this option. 399 400endchoice 401 402config SPARSEMEM 403 def_bool y 404 depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL 405 406config FLATMEM 407 def_bool y 408 depends on !SPARSEMEM || FLATMEM_MANUAL 409 410# 411# SPARSEMEM_EXTREME (which is the default) does some bootmem 412# allocations when sparse_init() is called. If this cannot 413# be done on your architecture, select this option. However, 414# statically allocating the mem_section[] array can potentially 415# consume vast quantities of .bss, so be careful. 416# 417# This option will also potentially produce smaller runtime code 418# with gcc 3.4 and later. 419# 420config SPARSEMEM_STATIC 421 bool 422 423# 424# Architecture platforms which require a two level mem_section in SPARSEMEM 425# must select this option. This is usually for architecture platforms with 426# an extremely sparse physical address space. 427# 428config SPARSEMEM_EXTREME 429 def_bool y 430 depends on SPARSEMEM && !SPARSEMEM_STATIC 431 432config SPARSEMEM_VMEMMAP_ENABLE 433 bool 434 435config SPARSEMEM_VMEMMAP 436 bool "Sparse Memory virtual memmap" 437 depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE 438 default y 439 help 440 SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise 441 pfn_to_page and page_to_pfn operations. This is the most 442 efficient option when sufficient kernel resources are available. 443 444config HAVE_MEMBLOCK_PHYS_MAP 445 bool 446 447config HAVE_FAST_GUP 448 depends on MMU 449 bool 450 451# Don't discard allocated memory used to track "memory" and "reserved" memblocks 452# after early boot, so it can still be used to test for validity of memory. 453# Also, memblocks are updated with memory hot(un)plug. 454config ARCH_KEEP_MEMBLOCK 455 bool 456 457# Keep arch NUMA mapping infrastructure post-init. 458config NUMA_KEEP_MEMINFO 459 bool 460 461config MEMORY_ISOLATION 462 bool 463 464# IORESOURCE_SYSTEM_RAM regions in the kernel resource tree that are marked 465# IORESOURCE_EXCLUSIVE cannot be mapped to user space, for example, via 466# /dev/mem. 467config EXCLUSIVE_SYSTEM_RAM 468 def_bool y 469 depends on !DEVMEM || STRICT_DEVMEM 470 471# 472# Only be set on architectures that have completely implemented memory hotplug 473# feature. If you are not sure, don't touch it. 474# 475config HAVE_BOOTMEM_INFO_NODE 476 def_bool n 477 478config ARCH_ENABLE_MEMORY_HOTPLUG 479 bool 480 481config ARCH_ENABLE_MEMORY_HOTREMOVE 482 bool 483 484# eventually, we can have this option just 'select SPARSEMEM' 485menuconfig MEMORY_HOTPLUG 486 bool "Memory hotplug" 487 select MEMORY_ISOLATION 488 depends on SPARSEMEM 489 depends on ARCH_ENABLE_MEMORY_HOTPLUG 490 depends on 64BIT 491 select NUMA_KEEP_MEMINFO if NUMA 492 493if MEMORY_HOTPLUG 494 495config MEMORY_HOTPLUG_DEFAULT_ONLINE 496 bool "Online the newly added memory blocks by default" 497 depends on MEMORY_HOTPLUG 498 help 499 This option sets the default policy setting for memory hotplug 500 onlining policy (/sys/devices/system/memory/auto_online_blocks) which 501 determines what happens to newly added memory regions. Policy setting 502 can always be changed at runtime. 503 See Documentation/admin-guide/mm/memory-hotplug.rst for more information. 504 505 Say Y here if you want all hot-plugged memory blocks to appear in 506 'online' state by default. 507 Say N here if you want the default policy to keep all hot-plugged 508 memory blocks in 'offline' state. 509 510config MEMORY_HOTREMOVE 511 bool "Allow for memory hot remove" 512 select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64) 513 depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE 514 depends on MIGRATION 515 516config MHP_MEMMAP_ON_MEMORY 517 def_bool y 518 depends on MEMORY_HOTPLUG && SPARSEMEM_VMEMMAP 519 depends on ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE 520 521endif # MEMORY_HOTPLUG 522 523# Heavily threaded applications may benefit from splitting the mm-wide 524# page_table_lock, so that faults on different parts of the user address 525# space can be handled with less contention: split it at this NR_CPUS. 526# Default to 4 for wider testing, though 8 might be more appropriate. 527# ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. 528# PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. 529# SPARC32 allocates multiple pte tables within a single page, and therefore 530# a per-page lock leads to problems when multiple tables need to be locked 531# at the same time (e.g. copy_page_range()). 532# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. 533# 534config SPLIT_PTLOCK_CPUS 535 int 536 default "999999" if !MMU 537 default "999999" if ARM && !CPU_CACHE_VIPT 538 default "999999" if PARISC && !PA20 539 default "999999" if SPARC32 540 default "4" 541 542config ARCH_ENABLE_SPLIT_PMD_PTLOCK 543 bool 544 545# 546# support for memory balloon 547config MEMORY_BALLOON 548 bool 549 550# 551# support for memory balloon compaction 552config BALLOON_COMPACTION 553 bool "Allow for balloon memory compaction/migration" 554 def_bool y 555 depends on COMPACTION && MEMORY_BALLOON 556 help 557 Memory fragmentation introduced by ballooning might reduce 558 significantly the number of 2MB contiguous memory blocks that can be 559 used within a guest, thus imposing performance penalties associated 560 with the reduced number of transparent huge pages that could be used 561 by the guest workload. Allowing the compaction & migration for memory 562 pages enlisted as being part of memory balloon devices avoids the 563 scenario aforementioned and helps improving memory defragmentation. 564 565# 566# support for memory compaction 567config COMPACTION 568 bool "Allow for memory compaction" 569 def_bool y 570 select MIGRATION 571 depends on MMU 572 help 573 Compaction is the only memory management component to form 574 high order (larger physically contiguous) memory blocks 575 reliably. The page allocator relies on compaction heavily and 576 the lack of the feature can lead to unexpected OOM killer 577 invocations for high order memory requests. You shouldn't 578 disable this option unless there really is a strong reason for 579 it and then we would be really interested to hear about that at 580 linux-mm@kvack.org. 581 582config COMPACT_UNEVICTABLE_DEFAULT 583 int 584 depends on COMPACTION 585 default 0 if PREEMPT_RT 586 default 1 587 588# 589# support for free page reporting 590config PAGE_REPORTING 591 bool "Free page reporting" 592 def_bool n 593 help 594 Free page reporting allows for the incremental acquisition of 595 free pages from the buddy allocator for the purpose of reporting 596 those pages to another entity, such as a hypervisor, so that the 597 memory can be freed within the host for other uses. 598 599# 600# support for page migration 601# 602config MIGRATION 603 bool "Page migration" 604 def_bool y 605 depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU 606 help 607 Allows the migration of the physical location of pages of processes 608 while the virtual addresses are not changed. This is useful in 609 two situations. The first is on NUMA systems to put pages nearer 610 to the processors accessing. The second is when allocating huge 611 pages as migration can relocate pages to satisfy a huge page 612 allocation instead of reclaiming. 613 614config DEVICE_MIGRATION 615 def_bool MIGRATION && ZONE_DEVICE 616 617config ARCH_ENABLE_HUGEPAGE_MIGRATION 618 bool 619 620config ARCH_ENABLE_THP_MIGRATION 621 bool 622 623config HUGETLB_PAGE_SIZE_VARIABLE 624 def_bool n 625 help 626 Allows the pageblock_order value to be dynamic instead of just standard 627 HUGETLB_PAGE_ORDER when there are multiple HugeTLB page sizes available 628 on a platform. 629 630 Note that the pageblock_order cannot exceed MAX_ORDER - 1 and will be 631 clamped down to MAX_ORDER - 1. 632 633config CONTIG_ALLOC 634 def_bool (MEMORY_ISOLATION && COMPACTION) || CMA 635 636config PHYS_ADDR_T_64BIT 637 def_bool 64BIT 638 639config BOUNCE 640 bool "Enable bounce buffers" 641 default y 642 depends on BLOCK && MMU && HIGHMEM 643 help 644 Enable bounce buffers for devices that cannot access the full range of 645 memory available to the CPU. Enabled by default when HIGHMEM is 646 selected, but you may say n to override this. 647 648config MMU_NOTIFIER 649 bool 650 select SRCU 651 select INTERVAL_TREE 652 653config KSM 654 bool "Enable KSM for page merging" 655 depends on MMU 656 select XXHASH 657 help 658 Enable Kernel Samepage Merging: KSM periodically scans those areas 659 of an application's address space that an app has advised may be 660 mergeable. When it finds pages of identical content, it replaces 661 the many instances by a single page with that content, so 662 saving memory until one or another app needs to modify the content. 663 Recommended for use with KVM, or with other duplicative applications. 664 See Documentation/mm/ksm.rst for more information: KSM is inactive 665 until a program has madvised that an area is MADV_MERGEABLE, and 666 root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set). 667 668config DEFAULT_MMAP_MIN_ADDR 669 int "Low address space to protect from user allocation" 670 depends on MMU 671 default 4096 672 help 673 This is the portion of low virtual memory which should be protected 674 from userspace allocation. Keeping a user from writing to low pages 675 can help reduce the impact of kernel NULL pointer bugs. 676 677 For most ia64, ppc64 and x86 users with lots of address space 678 a value of 65536 is reasonable and should cause no problems. 679 On arm and other archs it should not be higher than 32768. 680 Programs which use vm86 functionality or have some need to map 681 this low address space will need CAP_SYS_RAWIO or disable this 682 protection by setting the value to 0. 683 684 This value can be changed after boot using the 685 /proc/sys/vm/mmap_min_addr tunable. 686 687config ARCH_SUPPORTS_MEMORY_FAILURE 688 bool 689 690config MEMORY_FAILURE 691 depends on MMU 692 depends on ARCH_SUPPORTS_MEMORY_FAILURE 693 bool "Enable recovery from hardware memory errors" 694 select MEMORY_ISOLATION 695 select RAS 696 help 697 Enables code to recover from some memory failures on systems 698 with MCA recovery. This allows a system to continue running 699 even when some of its memory has uncorrected errors. This requires 700 special hardware support and typically ECC memory. 701 702config HWPOISON_INJECT 703 tristate "HWPoison pages injector" 704 depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS 705 select PROC_PAGE_MONITOR 706 707config NOMMU_INITIAL_TRIM_EXCESS 708 int "Turn on mmap() excess space trimming before booting" 709 depends on !MMU 710 default 1 711 help 712 The NOMMU mmap() frequently needs to allocate large contiguous chunks 713 of memory on which to store mappings, but it can only ask the system 714 allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently 715 more than it requires. To deal with this, mmap() is able to trim off 716 the excess and return it to the allocator. 717 718 If trimming is enabled, the excess is trimmed off and returned to the 719 system allocator, which can cause extra fragmentation, particularly 720 if there are a lot of transient processes. 721 722 If trimming is disabled, the excess is kept, but not used, which for 723 long-term mappings means that the space is wasted. 724 725 Trimming can be dynamically controlled through a sysctl option 726 (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of 727 excess pages there must be before trimming should occur, or zero if 728 no trimming is to occur. 729 730 This option specifies the initial value of this option. The default 731 of 1 says that all excess pages should be trimmed. 732 733 See Documentation/admin-guide/mm/nommu-mmap.rst for more information. 734 735config ARCH_WANT_GENERAL_HUGETLB 736 bool 737 738config ARCH_WANTS_THP_SWAP 739 def_bool n 740 741menuconfig TRANSPARENT_HUGEPAGE 742 bool "Transparent Hugepage Support" 743 depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE && !PREEMPT_RT 744 select COMPACTION 745 select XARRAY_MULTI 746 help 747 Transparent Hugepages allows the kernel to use huge pages and 748 huge tlb transparently to the applications whenever possible. 749 This feature can improve computing performance to certain 750 applications by speeding up page faults during memory 751 allocation, by reducing the number of tlb misses and by speeding 752 up the pagetable walking. 753 754 If memory constrained on embedded, you may want to say N. 755 756if TRANSPARENT_HUGEPAGE 757 758choice 759 prompt "Transparent Hugepage Support sysfs defaults" 760 depends on TRANSPARENT_HUGEPAGE 761 default TRANSPARENT_HUGEPAGE_ALWAYS 762 help 763 Selects the sysfs defaults for Transparent Hugepage Support. 764 765 config TRANSPARENT_HUGEPAGE_ALWAYS 766 bool "always" 767 help 768 Enabling Transparent Hugepage always, can increase the 769 memory footprint of applications without a guaranteed 770 benefit but it will work automatically for all applications. 771 772 config TRANSPARENT_HUGEPAGE_MADVISE 773 bool "madvise" 774 help 775 Enabling Transparent Hugepage madvise, will only provide a 776 performance improvement benefit to the applications using 777 madvise(MADV_HUGEPAGE) but it won't risk to increase the 778 memory footprint of applications without a guaranteed 779 benefit. 780endchoice 781 782config THP_SWAP 783 def_bool y 784 depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP 785 help 786 Swap transparent huge pages in one piece, without splitting. 787 XXX: For now, swap cluster backing transparent huge page 788 will be split after swapout. 789 790 For selection by architectures with reasonable THP sizes. 791 792config READ_ONLY_THP_FOR_FS 793 bool "Read-only THP for filesystems (EXPERIMENTAL)" 794 depends on TRANSPARENT_HUGEPAGE && SHMEM 795 796 help 797 Allow khugepaged to put read-only file-backed pages in THP. 798 799 This is marked experimental because it is a new feature. Write 800 support of file THPs will be developed in the next few release 801 cycles. 802 803endif # TRANSPARENT_HUGEPAGE 804 805# 806# UP and nommu archs use km based percpu allocator 807# 808config NEED_PER_CPU_KM 809 depends on !SMP || !MMU 810 bool 811 default y 812 813config NEED_PER_CPU_EMBED_FIRST_CHUNK 814 bool 815 816config NEED_PER_CPU_PAGE_FIRST_CHUNK 817 bool 818 819config USE_PERCPU_NUMA_NODE_ID 820 bool 821 822config HAVE_SETUP_PER_CPU_AREA 823 bool 824 825config FRONTSWAP 826 bool 827 828config CMA 829 bool "Contiguous Memory Allocator" 830 depends on MMU 831 select MIGRATION 832 select MEMORY_ISOLATION 833 help 834 This enables the Contiguous Memory Allocator which allows other 835 subsystems to allocate big physically-contiguous blocks of memory. 836 CMA reserves a region of memory and allows only movable pages to 837 be allocated from it. This way, the kernel can use the memory for 838 pagecache and when a subsystem requests for contiguous area, the 839 allocated pages are migrated away to serve the contiguous request. 840 841 If unsure, say "n". 842 843config CMA_DEBUG 844 bool "CMA debug messages (DEVELOPMENT)" 845 depends on DEBUG_KERNEL && CMA 846 help 847 Turns on debug messages in CMA. This produces KERN_DEBUG 848 messages for every CMA call as well as various messages while 849 processing calls such as dma_alloc_from_contiguous(). 850 This option does not affect warning and error messages. 851 852config CMA_DEBUGFS 853 bool "CMA debugfs interface" 854 depends on CMA && DEBUG_FS 855 help 856 Turns on the DebugFS interface for CMA. 857 858config CMA_SYSFS 859 bool "CMA information through sysfs interface" 860 depends on CMA && SYSFS 861 help 862 This option exposes some sysfs attributes to get information 863 from CMA. 864 865config CMA_AREAS 866 int "Maximum count of the CMA areas" 867 depends on CMA 868 default 19 if NUMA 869 default 7 870 help 871 CMA allows to create CMA areas for particular purpose, mainly, 872 used as device private area. This parameter sets the maximum 873 number of CMA area in the system. 874 875 If unsure, leave the default value "7" in UMA and "19" in NUMA. 876 877config MEM_SOFT_DIRTY 878 bool "Track memory changes" 879 depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS 880 select PROC_PAGE_MONITOR 881 help 882 This option enables memory changes tracking by introducing a 883 soft-dirty bit on pte-s. This bit it set when someone writes 884 into a page just as regular dirty bit, but unlike the latter 885 it can be cleared by hands. 886 887 See Documentation/admin-guide/mm/soft-dirty.rst for more details. 888 889config GENERIC_EARLY_IOREMAP 890 bool 891 892config STACK_MAX_DEFAULT_SIZE_MB 893 int "Default maximum user stack size for 32-bit processes (MB)" 894 default 100 895 range 8 2048 896 depends on STACK_GROWSUP && (!64BIT || COMPAT) 897 help 898 This is the maximum stack size in Megabytes in the VM layout of 32-bit 899 user processes when the stack grows upwards (currently only on parisc 900 arch) when the RLIMIT_STACK hard limit is unlimited. 901 902 A sane initial value is 100 MB. 903 904config DEFERRED_STRUCT_PAGE_INIT 905 bool "Defer initialisation of struct pages to kthreads" 906 depends on SPARSEMEM 907 depends on !NEED_PER_CPU_KM 908 depends on 64BIT 909 select PADATA 910 help 911 Ordinarily all struct pages are initialised during early boot in a 912 single thread. On very large machines this can take a considerable 913 amount of time. If this option is set, large machines will bring up 914 a subset of memmap at boot and then initialise the rest in parallel. 915 This has a potential performance impact on tasks running early in the 916 lifetime of the system until these kthreads finish the 917 initialisation. 918 919config PAGE_IDLE_FLAG 920 bool 921 select PAGE_EXTENSION if !64BIT 922 help 923 This adds PG_idle and PG_young flags to 'struct page'. PTE Accessed 924 bit writers can set the state of the bit in the flags so that PTE 925 Accessed bit readers may avoid disturbance. 926 927config IDLE_PAGE_TRACKING 928 bool "Enable idle page tracking" 929 depends on SYSFS && MMU 930 select PAGE_IDLE_FLAG 931 help 932 This feature allows to estimate the amount of user pages that have 933 not been touched during a given period of time. This information can 934 be useful to tune memory cgroup limits and/or for job placement 935 within a compute cluster. 936 937 See Documentation/admin-guide/mm/idle_page_tracking.rst for 938 more details. 939 940config ARCH_HAS_CACHE_LINE_SIZE 941 bool 942 943config ARCH_HAS_CURRENT_STACK_POINTER 944 bool 945 help 946 In support of HARDENED_USERCOPY performing stack variable lifetime 947 checking, an architecture-agnostic way to find the stack pointer 948 is needed. Once an architecture defines an unsigned long global 949 register alias named "current_stack_pointer", this config can be 950 selected. 951 952config ARCH_HAS_PTE_DEVMAP 953 bool 954 955config ARCH_HAS_ZONE_DMA_SET 956 bool 957 958config ZONE_DMA 959 bool "Support DMA zone" if ARCH_HAS_ZONE_DMA_SET 960 default y if ARM64 || X86 961 962config ZONE_DMA32 963 bool "Support DMA32 zone" if ARCH_HAS_ZONE_DMA_SET 964 depends on !X86_32 965 default y if ARM64 966 967config ZONE_DEVICE 968 bool "Device memory (pmem, HMM, etc...) hotplug support" 969 depends on MEMORY_HOTPLUG 970 depends on MEMORY_HOTREMOVE 971 depends on SPARSEMEM_VMEMMAP 972 depends on ARCH_HAS_PTE_DEVMAP 973 select XARRAY_MULTI 974 975 help 976 Device memory hotplug support allows for establishing pmem, 977 or other device driver discovered memory regions, in the 978 memmap. This allows pfn_to_page() lookups of otherwise 979 "device-physical" addresses which is needed for using a DAX 980 mapping in an O_DIRECT operation, among other things. 981 982 If FS_DAX is enabled, then say Y. 983 984# 985# Helpers to mirror range of the CPU page tables of a process into device page 986# tables. 987# 988config HMM_MIRROR 989 bool 990 depends on MMU 991 992config GET_FREE_REGION 993 depends on SPARSEMEM 994 bool 995 996config DEVICE_PRIVATE 997 bool "Unaddressable device memory (GPU memory, ...)" 998 depends on ZONE_DEVICE 999 select GET_FREE_REGION 1000 1001 help 1002 Allows creation of struct pages to represent unaddressable device 1003 memory; i.e., memory that is only accessible from the device (or 1004 group of devices). You likely also want to select HMM_MIRROR. 1005 1006config VMAP_PFN 1007 bool 1008 1009config ARCH_USES_HIGH_VMA_FLAGS 1010 bool 1011config ARCH_HAS_PKEYS 1012 bool 1013 1014config VM_EVENT_COUNTERS 1015 default y 1016 bool "Enable VM event counters for /proc/vmstat" if EXPERT 1017 help 1018 VM event counters are needed for event counts to be shown. 1019 This option allows the disabling of the VM event counters 1020 on EXPERT systems. /proc/vmstat will only show page counts 1021 if VM event counters are disabled. 1022 1023config PERCPU_STATS 1024 bool "Collect percpu memory statistics" 1025 help 1026 This feature collects and exposes statistics via debugfs. The 1027 information includes global and per chunk statistics, which can 1028 be used to help understand percpu memory usage. 1029 1030config GUP_TEST 1031 bool "Enable infrastructure for get_user_pages()-related unit tests" 1032 depends on DEBUG_FS 1033 help 1034 Provides /sys/kernel/debug/gup_test, which in turn provides a way 1035 to make ioctl calls that can launch kernel-based unit tests for 1036 the get_user_pages*() and pin_user_pages*() family of API calls. 1037 1038 These tests include benchmark testing of the _fast variants of 1039 get_user_pages*() and pin_user_pages*(), as well as smoke tests of 1040 the non-_fast variants. 1041 1042 There is also a sub-test that allows running dump_page() on any 1043 of up to eight pages (selected by command line args) within the 1044 range of user-space addresses. These pages are either pinned via 1045 pin_user_pages*(), or pinned via get_user_pages*(), as specified 1046 by other command line arguments. 1047 1048 See tools/testing/selftests/vm/gup_test.c 1049 1050comment "GUP_TEST needs to have DEBUG_FS enabled" 1051 depends on !GUP_TEST && !DEBUG_FS 1052 1053config GUP_GET_PTE_LOW_HIGH 1054 bool 1055 1056config ARCH_HAS_PTE_SPECIAL 1057 bool 1058 1059# 1060# Some architectures require a special hugepage directory format that is 1061# required to support multiple hugepage sizes. For example a4fe3ce76 1062# "powerpc/mm: Allow more flexible layouts for hugepage pagetables" 1063# introduced it on powerpc. This allows for a more flexible hugepage 1064# pagetable layouts. 1065# 1066config ARCH_HAS_HUGEPD 1067 bool 1068 1069config MAPPING_DIRTY_HELPERS 1070 bool 1071 1072config KMAP_LOCAL 1073 bool 1074 1075config KMAP_LOCAL_NON_LINEAR_PTE_ARRAY 1076 bool 1077 1078# struct io_mapping based helper. Selected by drivers that need them 1079config IO_MAPPING 1080 bool 1081 1082config SECRETMEM 1083 def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED 1084 1085config ANON_VMA_NAME 1086 bool "Anonymous VMA name support" 1087 depends on PROC_FS && ADVISE_SYSCALLS && MMU 1088 1089 help 1090 Allow naming anonymous virtual memory areas. 1091 1092 This feature allows assigning names to virtual memory areas. Assigned 1093 names can be later retrieved from /proc/pid/maps and /proc/pid/smaps 1094 and help identifying individual anonymous memory areas. 1095 Assigning a name to anonymous virtual memory area might prevent that 1096 area from being merged with adjacent virtual memory areas due to the 1097 difference in their name. 1098 1099config USERFAULTFD 1100 bool "Enable userfaultfd() system call" 1101 depends on MMU 1102 help 1103 Enable the userfaultfd() system call that allows to intercept and 1104 handle page faults in userland. 1105 1106config HAVE_ARCH_USERFAULTFD_WP 1107 bool 1108 help 1109 Arch has userfaultfd write protection support 1110 1111config HAVE_ARCH_USERFAULTFD_MINOR 1112 bool 1113 help 1114 Arch has userfaultfd minor fault support 1115 1116config PTE_MARKER 1117 bool 1118 1119 help 1120 Allows to create marker PTEs for file-backed memory. 1121 1122config PTE_MARKER_UFFD_WP 1123 bool "Userfaultfd write protection support for shmem/hugetlbfs" 1124 default y 1125 depends on HAVE_ARCH_USERFAULTFD_WP 1126 select PTE_MARKER 1127 1128 help 1129 Allows to create marker PTEs for userfaultfd write protection 1130 purposes. It is required to enable userfaultfd write protection on 1131 file-backed memory types like shmem and hugetlbfs. 1132 1133source "mm/damon/Kconfig" 1134 1135endmenu 1136