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