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