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 12menuconfig SWAP 13 bool "Support for paging of anonymous memory (swap)" 14 depends on MMU && BLOCK && !ARCH_NO_SWAP 15 default y 16 help 17 This option allows you to choose whether you want to have support 18 for so called swap devices or swap files in your kernel that are 19 used to provide more virtual memory than the actual RAM present 20 in your computer. If unsure say Y. 21 22config ZSWAP 23 bool "Compressed cache for swap pages" 24 depends on SWAP 25 select CRYPTO 26 select ZSMALLOC 27 help 28 A lightweight compressed cache for swap pages. It takes 29 pages that are in the process of being swapped out and attempts to 30 compress them into a dynamically allocated RAM-based memory pool. 31 This can result in a significant I/O reduction on swap device and, 32 in the case where decompressing from RAM is faster than swap device 33 reads, can also improve workload performance. 34 35config ZSWAP_DEFAULT_ON 36 bool "Enable the compressed cache for swap pages by default" 37 depends on ZSWAP 38 help 39 If selected, the compressed cache for swap pages will be enabled 40 at boot, otherwise it will be disabled. 41 42 The selection made here can be overridden by using the kernel 43 command line 'zswap.enabled=' option. 44 45config ZSWAP_SHRINKER_DEFAULT_ON 46 bool "Shrink the zswap pool on memory pressure" 47 depends on ZSWAP 48 default n 49 help 50 If selected, the zswap shrinker will be enabled, and the pages 51 stored in the zswap pool will become available for reclaim (i.e 52 written back to the backing swap device) on memory pressure. 53 54 This means that zswap writeback could happen even if the pool is 55 not yet full, or the cgroup zswap limit has not been reached, 56 reducing the chance that cold pages will reside in the zswap pool 57 and consume memory indefinitely. 58 59choice 60 prompt "Default compressor" 61 depends on ZSWAP 62 default ZSWAP_COMPRESSOR_DEFAULT_LZO 63 help 64 Selects the default compression algorithm for the compressed cache 65 for swap pages. 66 67 For an overview what kind of performance can be expected from 68 a particular compression algorithm please refer to the benchmarks 69 available at the following LWN page: 70 https://lwn.net/Articles/751795/ 71 72 If in doubt, select 'LZO'. 73 74 The selection made here can be overridden by using the kernel 75 command line 'zswap.compressor=' option. 76 77config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE 78 bool "Deflate" 79 select CRYPTO_DEFLATE 80 help 81 Use the Deflate algorithm as the default compression algorithm. 82 83config ZSWAP_COMPRESSOR_DEFAULT_LZO 84 bool "LZO" 85 select CRYPTO_LZO 86 help 87 Use the LZO algorithm as the default compression algorithm. 88 89config ZSWAP_COMPRESSOR_DEFAULT_842 90 bool "842" 91 select CRYPTO_842 92 help 93 Use the 842 algorithm as the default compression algorithm. 94 95config ZSWAP_COMPRESSOR_DEFAULT_LZ4 96 bool "LZ4" 97 select CRYPTO_LZ4 98 help 99 Use the LZ4 algorithm as the default compression algorithm. 100 101config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC 102 bool "LZ4HC" 103 select CRYPTO_LZ4HC 104 help 105 Use the LZ4HC algorithm as the default compression algorithm. 106 107config ZSWAP_COMPRESSOR_DEFAULT_ZSTD 108 bool "zstd" 109 select CRYPTO_ZSTD 110 help 111 Use the zstd algorithm as the default compression algorithm. 112endchoice 113 114config ZSWAP_COMPRESSOR_DEFAULT 115 string 116 depends on ZSWAP 117 default "deflate" if ZSWAP_COMPRESSOR_DEFAULT_DEFLATE 118 default "lzo" if ZSWAP_COMPRESSOR_DEFAULT_LZO 119 default "842" if ZSWAP_COMPRESSOR_DEFAULT_842 120 default "lz4" if ZSWAP_COMPRESSOR_DEFAULT_LZ4 121 default "lz4hc" if ZSWAP_COMPRESSOR_DEFAULT_LZ4HC 122 default "zstd" if ZSWAP_COMPRESSOR_DEFAULT_ZSTD 123 default "" 124 125config ZSMALLOC 126 tristate 127 128if ZSMALLOC 129 130menu "Zsmalloc allocator options" 131 depends on ZSMALLOC 132 133comment "Zsmalloc is a common backend allocator for zswap & zram" 134 135config ZSMALLOC_STAT 136 bool "Export zsmalloc statistics" 137 select DEBUG_FS 138 help 139 This option enables code in the zsmalloc to collect various 140 statistics about what's happening in zsmalloc and exports that 141 information to userspace via debugfs. 142 If unsure, say N. 143 144config ZSMALLOC_CHAIN_SIZE 145 int "Maximum number of physical pages per-zspage" 146 default 8 147 range 4 16 148 help 149 This option sets the upper limit on the number of physical pages 150 that a zmalloc page (zspage) can consist of. The optimal zspage 151 chain size is calculated for each size class during the 152 initialization of the pool. 153 154 Changing this option can alter the characteristics of size classes, 155 such as the number of pages per zspage and the number of objects 156 per zspage. This can also result in different configurations of 157 the pool, as zsmalloc merges size classes with similar 158 characteristics. 159 160 For more information, see zsmalloc documentation. 161 162endmenu 163 164endif 165 166menu "Slab allocator options" 167 168config SLUB 169 def_bool y 170 select IRQ_WORK 171 172config KVFREE_RCU_BATCHED 173 def_bool y 174 depends on !SLUB_TINY && !TINY_RCU 175 depends on !RCU_STRICT_GRACE_PERIOD 176 177config SLUB_TINY 178 bool "Configure for minimal memory footprint" 179 depends on EXPERT && !COMPILE_TEST 180 select SLAB_MERGE_DEFAULT 181 help 182 Configures the slab allocator in a way to achieve minimal memory 183 footprint, sacrificing scalability, debugging and other features. 184 This is intended only for the smallest system that had used the 185 SLOB allocator and is not recommended for systems with more than 186 16MB RAM. 187 188 If unsure, say N. 189 190config SLAB_MERGE_DEFAULT 191 bool "Allow slab caches to be merged" 192 default y 193 help 194 For reduced kernel memory fragmentation, slab caches can be 195 merged when they share the same size and other characteristics. 196 This carries a risk of kernel heap overflows being able to 197 overwrite objects from merged caches (and more easily control 198 cache layout), which makes such heap attacks easier to exploit 199 by attackers. By keeping caches unmerged, these kinds of exploits 200 can usually only damage objects in the same cache. To disable 201 merging at runtime, "slab_nomerge" can be passed on the kernel 202 command line. 203 204config SLAB_FREELIST_RANDOM 205 bool "Randomize slab freelist" 206 depends on !SLUB_TINY 207 help 208 Randomizes the freelist order used on creating new pages. This 209 security feature reduces the predictability of the kernel slab 210 allocator against heap overflows. 211 212config SLAB_FREELIST_HARDENED 213 bool "Harden slab freelist metadata" 214 depends on !SLUB_TINY 215 help 216 Many kernel heap attacks try to target slab cache metadata and 217 other infrastructure. This options makes minor performance 218 sacrifices to harden the kernel slab allocator against common 219 freelist exploit methods. 220 221config SLAB_BUCKETS 222 bool "Support allocation from separate kmalloc buckets" 223 depends on !SLUB_TINY 224 default SLAB_FREELIST_HARDENED 225 help 226 Kernel heap attacks frequently depend on being able to create 227 specifically-sized allocations with user-controlled contents 228 that will be allocated into the same kmalloc bucket as a 229 target object. To avoid sharing these allocation buckets, 230 provide an explicitly separated set of buckets to be used for 231 user-controlled allocations. This may very slightly increase 232 memory fragmentation, though in practice it's only a handful 233 of extra pages since the bulk of user-controlled allocations 234 are relatively long-lived. 235 236 If unsure, say Y. 237 238config SLUB_STATS 239 default n 240 bool "Enable performance statistics" 241 depends on SYSFS && !SLUB_TINY 242 help 243 The statistics are useful to debug slab allocation behavior in 244 order find ways to optimize the allocator. This should never be 245 enabled for production use since keeping statistics slows down 246 the allocator by a few percentage points. The slabinfo command 247 supports the determination of the most active slabs to figure 248 out which slabs are relevant to a particular load. 249 Try running: slabinfo -DA 250 251config KMALLOC_PARTITION_CACHES 252 depends on !SLUB_TINY 253 bool "Partitioned slab caches for normal kmalloc" 254 default RANDOM_KMALLOC_CACHES 255 help 256 A hardening feature that creates multiple isolated copies of slab 257 caches for normal kmalloc allocations. This makes it more difficult 258 to exploit memory-safety vulnerabilities by attacking vulnerable 259 co-located memory objects. Several modes are provided. 260 261 Currently the number of copies is set to 16, a reasonably large value 262 that effectively diverges the memory objects allocated for different 263 subsystems or modules into different caches, at the expense of a 264 limited degree of memory and CPU overhead that relates to hardware 265 and system workload. 266 267choice 268 prompt "Partitioned slab cache mode" 269 depends on KMALLOC_PARTITION_CACHES 270 default KMALLOC_PARTITION_TYPED if CC_HAS_ALLOC_TOKEN 271 default KMALLOC_PARTITION_RANDOM 272 help 273 Selects the slab cache partitioning mode. 274 275config KMALLOC_PARTITION_RANDOM 276 bool "Randomize slab caches for normal kmalloc" 277 help 278 Randomly pick a slab cache based on code address and a per-boot 279 random seed. 280 281 This makes it harder for attackers to predict object co-location. 282 The placement is random: while attackers don't know which kmalloc 283 cache an object will be allocated from, they might circumvent 284 the randomization by retrying attacks across multiple machines until 285 the target objects are co-located. 286 287config KMALLOC_PARTITION_TYPED 288 bool "Type based slab cache selection for normal kmalloc" 289 depends on CC_HAS_ALLOC_TOKEN 290 help 291 Rely on Clang's allocation tokens to choose a slab cache, where token 292 IDs are derived from the allocated type. 293 294 Unlike KMALLOC_PARTITION_RANDOM, cache assignment is deterministic based 295 on type, which guarantees that objects of certain types are not 296 placed in the same cache. This effectively mitigates certain classes 297 of exploits that probabilistic defenses like KMALLOC_PARTITION_RANDOM 298 only make harder but not impossible. However, this also means the 299 cache assignment is predictable. 300 301 Clang's default token ID calculation returns a bounded hash with 302 disjoint ranges for pointer-containing and pointerless objects: when 303 used as the slab cache index, this prevents buffer overflows on 304 primitive buffers from directly corrupting pointer-containing 305 objects. 306 307 The current effectiveness of Clang's type inference can be judged by 308 -Rpass=alloc-token, which provides diagnostics where (after dead-code 309 elimination) type inference failed. 310 311 Requires Clang 22 or later. 312 313endchoice 314 315config RANDOM_KMALLOC_CACHES 316 bool 317 transitional 318 help 319 Transitional config for migration to KMALLOC_PARTITION_CACHES. 320 321endmenu # Slab allocator options 322 323config SHUFFLE_PAGE_ALLOCATOR 324 bool "Page allocator randomization" 325 default SLAB_FREELIST_RANDOM && ACPI_NUMA 326 help 327 Randomization of the page allocator improves the average 328 utilization of a direct-mapped memory-side-cache. See section 329 5.2.27 Heterogeneous Memory Attribute Table (HMAT) in the ACPI 330 6.2a specification for an example of how a platform advertises 331 the presence of a memory-side-cache. There are also incidental 332 security benefits as it reduces the predictability of page 333 allocations to compliment SLAB_FREELIST_RANDOM, but the 334 default granularity of shuffling on the MAX_PAGE_ORDER i.e, 10th 335 order of pages is selected based on cache utilization benefits 336 on x86. 337 338 While the randomization improves cache utilization it may 339 negatively impact workloads on platforms without a cache. For 340 this reason, by default, the randomization is not enabled even 341 if SHUFFLE_PAGE_ALLOCATOR=y. The randomization may be force enabled 342 with the 'page_alloc.shuffle' kernel command line parameter. 343 344 Say Y if unsure. 345 346config COMPAT_BRK 347 bool "Disable heap randomization" 348 default y 349 help 350 Randomizing heap placement makes heap exploits harder, but it 351 also breaks ancient binaries (including anything libc5 based). 352 This option changes the bootup default to heap randomization 353 disabled, and can be overridden at runtime by setting 354 /proc/sys/kernel/randomize_va_space to 2. 355 356 On non-ancient distros (post-2000 ones) N is usually a safe choice. 357 358config MMAP_ALLOW_UNINITIALIZED 359 bool "Allow mmapped anonymous memory to be uninitialized" 360 depends on EXPERT && !MMU 361 default n 362 help 363 Normally, and according to the Linux spec, anonymous memory obtained 364 from mmap() has its contents cleared before it is passed to 365 userspace. Enabling this config option allows you to request that 366 mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus 367 providing a huge performance boost. If this option is not enabled, 368 then the flag will be ignored. 369 370 This is taken advantage of by uClibc's malloc(), and also by 371 ELF-FDPIC binfmt's brk and stack allocator. 372 373 Because of the obvious security issues, this option should only be 374 enabled on embedded devices where you control what is run in 375 userspace. Since that isn't generally a problem on no-MMU systems, 376 it is normally safe to say Y here. 377 378 See Documentation/admin-guide/mm/nommu-mmap.rst for more information. 379 380config SELECT_MEMORY_MODEL 381 def_bool y 382 depends on ARCH_SELECT_MEMORY_MODEL 383 384choice 385 prompt "Memory model" 386 depends on SELECT_MEMORY_MODEL 387 default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT 388 default FLATMEM_MANUAL 389 help 390 This option allows you to change some of the ways that 391 Linux manages its memory internally. Most users will 392 only have one option here selected by the architecture 393 configuration. This is normal. 394 395config FLATMEM_MANUAL 396 bool "Flat Memory" 397 depends on !ARCH_SPARSEMEM_ENABLE || ARCH_FLATMEM_ENABLE 398 help 399 This option is best suited for non-NUMA systems with 400 flat address space. The FLATMEM is the most efficient 401 system in terms of performance and resource consumption 402 and it is the best option for smaller systems. 403 404 For systems that have holes in their physical address 405 spaces and for features like NUMA and memory hotplug, 406 choose "Sparse Memory". 407 408 If unsure, choose this option (Flat Memory) over any other. 409 410config SPARSEMEM_MANUAL 411 bool "Sparse Memory" 412 depends on ARCH_SPARSEMEM_ENABLE 413 help 414 This will be the only option for some systems, including 415 memory hot-plug systems. This is normal. 416 417 This option provides efficient support for systems with 418 holes is their physical address space and allows memory 419 hot-plug and hot-remove. 420 421 If unsure, choose "Flat Memory" over this option. 422 423endchoice 424 425config SPARSEMEM 426 def_bool y 427 depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL 428 429config FLATMEM 430 def_bool y 431 depends on !SPARSEMEM || FLATMEM_MANUAL 432 433# 434# SPARSEMEM_EXTREME (which is the default) does some bootmem 435# allocations when sparse_init() is called. If this cannot 436# be done on your architecture, select this option. However, 437# statically allocating the mem_section[] array can potentially 438# consume vast quantities of .bss, so be careful. 439# 440# This option will also potentially produce smaller runtime code 441# with gcc 3.4 and later. 442# 443config SPARSEMEM_STATIC 444 bool 445 446# 447# Architecture platforms which require a two level mem_section in SPARSEMEM 448# must select this option. This is usually for architecture platforms with 449# an extremely sparse physical address space. 450# 451config SPARSEMEM_EXTREME 452 def_bool y 453 depends on SPARSEMEM && !SPARSEMEM_STATIC 454 455config SPARSEMEM_VMEMMAP_ENABLE 456 bool 457 458config SPARSEMEM_VMEMMAP 459 def_bool y 460 depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE 461 help 462 SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise 463 pfn_to_page and page_to_pfn operations. This is the most 464 efficient option when sufficient kernel resources are available. 465 466config SPARSEMEM_VMEMMAP_PREINIT 467 bool 468# 469# Select this config option from the architecture Kconfig, if it is preferred 470# to enable the feature of HugeTLB/dev_dax vmemmap optimization. 471# 472config ARCH_WANT_OPTIMIZE_DAX_VMEMMAP 473 bool 474 475config ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP 476 bool 477 478config ARCH_WANT_HUGETLB_VMEMMAP_PREINIT 479 bool 480 481config HAVE_MEMBLOCK_PHYS_MAP 482 bool 483 484config HAVE_GUP_FAST 485 depends on MMU 486 bool 487 488# Enable memblock support for scratch memory which is needed for kexec handover 489config MEMBLOCK_KHO_SCRATCH 490 bool 491 492# Don't discard allocated memory used to track "memory" and "reserved" memblocks 493# after early boot, so it can still be used to test for validity of memory. 494# Also, memblocks are updated with memory hot(un)plug. 495config ARCH_KEEP_MEMBLOCK 496 bool 497 498# Keep arch NUMA mapping infrastructure post-init. 499config NUMA_KEEP_MEMINFO 500 bool 501 502config MEMORY_ISOLATION 503 bool 504 505# IORESOURCE_SYSTEM_RAM regions in the kernel resource tree that are marked 506# IORESOURCE_EXCLUSIVE cannot be mapped to user space, for example, via 507# /dev/mem. 508config EXCLUSIVE_SYSTEM_RAM 509 def_bool y 510 depends on !DEVMEM || STRICT_DEVMEM 511 512# 513# Only be set on architectures that have completely implemented memory hotplug 514# feature. If you are not sure, don't touch it. 515# 516config HAVE_BOOTMEM_INFO_NODE 517 def_bool n 518 519config ARCH_ENABLE_MEMORY_HOTPLUG 520 bool 521 522# eventually, we can have this option just 'select SPARSEMEM' 523menuconfig MEMORY_HOTPLUG 524 bool "Memory hotplug" 525 select MEMORY_ISOLATION 526 depends on SPARSEMEM_VMEMMAP 527 depends on ARCH_ENABLE_MEMORY_HOTPLUG 528 depends on 64BIT 529 select NUMA_KEEP_MEMINFO if NUMA 530 531if MEMORY_HOTPLUG 532 533choice 534 prompt "Memory Hotplug Default Online Type" 535 default MHP_DEFAULT_ONLINE_TYPE_OFFLINE 536 help 537 Default memory type for hotplugged memory. 538 539 This option sets the default policy setting for memory hotplug 540 onlining policy (/sys/devices/system/memory/auto_online_blocks) which 541 determines what happens to newly added memory regions. Policy setting 542 can always be changed at runtime. 543 544 The default is 'offline'. 545 546 Select offline to defer onlining to drivers and user policy. 547 Select auto to let the kernel choose what zones to utilize. 548 Select online_kernel to generally allow kernel usage of this memory. 549 Select online_movable to generally disallow kernel usage of this memory. 550 551 Example kernel usage would be page structs and page tables. 552 553 See Documentation/admin-guide/mm/memory-hotplug.rst for more information. 554 555config MHP_DEFAULT_ONLINE_TYPE_OFFLINE 556 bool "offline" 557 help 558 Hotplugged memory will not be onlined by default. 559 Choose this for systems with drivers and user policy that 560 handle onlining of hotplug memory policy. 561 562config MHP_DEFAULT_ONLINE_TYPE_ONLINE_AUTO 563 bool "auto" 564 help 565 Select this if you want the kernel to automatically online 566 hotplugged memory into the zone it thinks is reasonable. 567 This memory may be utilized for kernel data. 568 569config MHP_DEFAULT_ONLINE_TYPE_ONLINE_KERNEL 570 bool "kernel" 571 help 572 Select this if you want the kernel to automatically online 573 hotplugged memory into a zone capable of being used for kernel 574 data. This typically means ZONE_NORMAL. 575 576config MHP_DEFAULT_ONLINE_TYPE_ONLINE_MOVABLE 577 bool "movable" 578 help 579 Select this if you want the kernel to automatically online 580 hotplug memory into ZONE_MOVABLE. This memory will generally 581 not be utilized for kernel data. 582 583 This should only be used when the admin knows sufficient 584 ZONE_NORMAL memory is available to describe hotplug memory, 585 otherwise hotplug memory may fail to online. For example, 586 sufficient kernel-capable memory (ZONE_NORMAL) must be 587 available to allocate page structs to describe ZONE_MOVABLE. 588 589endchoice 590 591config MEMORY_HOTREMOVE 592 bool "Allow for memory hot remove" 593 select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64) 594 depends on MEMORY_HOTPLUG 595 select MIGRATION 596 597config MHP_MEMMAP_ON_MEMORY 598 def_bool y 599 depends on MEMORY_HOTPLUG && SPARSEMEM_VMEMMAP 600 depends on ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE 601 602endif # MEMORY_HOTPLUG 603 604config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE 605 bool 606 607# Heavily threaded applications may benefit from splitting the mm-wide 608# page_table_lock, so that faults on different parts of the user address 609# space can be handled with less contention: split it at this NR_CPUS. 610# Default to 4 for wider testing, though 8 might be more appropriate. 611# ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. 612# PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. 613# SPARC32 allocates multiple pte tables within a single page, and therefore 614# a per-page lock leads to problems when multiple tables need to be locked 615# at the same time (e.g. copy_page_range()). 616# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. 617# 618config SPLIT_PTE_PTLOCKS 619 def_bool y 620 depends on MMU 621 depends on SMP 622 depends on NR_CPUS >= 4 623 depends on !ARM || CPU_CACHE_VIPT 624 depends on !PARISC || PA20 625 depends on !SPARC32 626 depends on !UML 627 628config ARCH_ENABLE_SPLIT_PMD_PTLOCK 629 bool 630 631config SPLIT_PMD_PTLOCKS 632 def_bool y 633 depends on SPLIT_PTE_PTLOCKS && ARCH_ENABLE_SPLIT_PMD_PTLOCK 634 635# 636# support for memory balloon 637config BALLOON 638 bool 639 640# 641# support for memory balloon page migration 642config BALLOON_MIGRATION 643 bool "Allow for balloon memory migration" 644 default y 645 depends on MIGRATION && BALLOON 646 help 647 Allow for migration of pages inflated in a memory balloon such that 648 they can be allocated from memory areas only available for movable 649 allocations (e.g., ZONE_MOVABLE, CMA) and such that they can be 650 migrated for memory defragmentation purposes by memory compaction. 651 652# 653# support for memory compaction 654config COMPACTION 655 bool "Allow for memory compaction" 656 default y 657 select MIGRATION 658 depends on MMU 659 help 660 Compaction is the only memory management component to form 661 high order (larger physically contiguous) memory blocks 662 reliably. The page allocator relies on compaction heavily and 663 the lack of the feature can lead to unexpected OOM killer 664 invocations for high order memory requests. You shouldn't 665 disable this option unless there really is a strong reason for 666 it and then we would be really interested to hear about that at 667 linux-mm@kvack.org. 668 669config COMPACT_UNEVICTABLE_DEFAULT 670 int 671 depends on COMPACTION 672 default 0 if PREEMPT_RT 673 default 1 674 675# 676# support for free page reporting 677config PAGE_REPORTING 678 bool "Free page reporting" 679 help 680 Free page reporting allows for the incremental acquisition of 681 free pages from the buddy allocator for the purpose of reporting 682 those pages to another entity, such as a hypervisor, so that the 683 memory can be freed within the host for other uses. 684 685config NUMA_MIGRATION 686 bool "NUMA page migration" 687 default y 688 depends on NUMA && MMU 689 select MIGRATION 690 help 691 Support the migration of pages to other NUMA nodes, available to 692 user space through interfaces like migrate_pages(), move_pages(), 693 and mbind(). Selecting this option also enables support for page 694 demotion for memory tiering. 695 696config MIGRATION 697 bool 698 depends on MMU 699 700config DEVICE_MIGRATION 701 def_bool MIGRATION && ZONE_DEVICE 702 703config ARCH_ENABLE_HUGEPAGE_MIGRATION 704 bool 705 706config ARCH_ENABLE_THP_MIGRATION 707 bool 708 709config HUGETLB_PAGE_SIZE_VARIABLE 710 def_bool n 711 help 712 Allows the pageblock_order value to be dynamic instead of just standard 713 HUGETLB_PAGE_ORDER when there are multiple HugeTLB page sizes available 714 on a platform. 715 716 Note that the pageblock_order cannot exceed MAX_PAGE_ORDER and will be 717 clamped down to MAX_PAGE_ORDER. 718 719config CONTIG_ALLOC 720 def_bool (MEMORY_ISOLATION && COMPACTION) || CMA 721 722config PCP_BATCH_SCALE_MAX 723 int "Maximum scale factor of PCP (Per-CPU pageset) batch allocate/free" 724 default 5 725 range 0 6 726 help 727 In page allocator, PCP (Per-CPU pageset) is refilled and drained in 728 batches. The batch number is scaled automatically to improve page 729 allocation/free throughput. But too large scale factor may hurt 730 latency. This option sets the upper limit of scale factor to limit 731 the maximum latency. 732 733config PHYS_ADDR_T_64BIT 734 def_bool 64BIT 735 736config MMU_NOTIFIER 737 bool 738 select INTERVAL_TREE 739 740config KSM 741 bool "Enable KSM for page merging" 742 depends on MMU 743 select XXHASH 744 help 745 Enable Kernel Samepage Merging: KSM periodically scans those areas 746 of an application's address space that an app has advised may be 747 mergeable. When it finds pages of identical content, it replaces 748 the many instances by a single page with that content, so 749 saving memory until one or another app needs to modify the content. 750 Recommended for use with KVM, or with other duplicative applications. 751 See Documentation/mm/ksm.rst for more information: KSM is inactive 752 until a program has madvised that an area is MADV_MERGEABLE, and 753 root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set). 754 755config DEFAULT_MMAP_MIN_ADDR 756 int "Low address space to protect from user allocation" 757 depends on MMU 758 default 4096 759 help 760 This is the portion of low virtual memory which should be protected 761 from userspace allocation. Keeping a user from writing to low pages 762 can help reduce the impact of kernel NULL pointer bugs. 763 764 For most arm64, ppc64 and x86 users with lots of address space 765 a value of 65536 is reasonable and should cause no problems. 766 On arm and other archs it should not be higher than 32768. 767 Programs which use vm86 functionality or have some need to map 768 this low address space will need CAP_SYS_RAWIO or disable this 769 protection by setting the value to 0. 770 771 This value can be changed after boot using the 772 /proc/sys/vm/mmap_min_addr tunable. 773 774config ARCH_SUPPORTS_MEMORY_FAILURE 775 bool 776 777config MEMORY_FAILURE 778 depends on MMU 779 depends on ARCH_SUPPORTS_MEMORY_FAILURE 780 bool "Enable recovery from hardware memory errors" 781 select INTERVAL_TREE 782 help 783 Enables code to recover from some memory failures on systems 784 with MCA recovery. This allows a system to continue running 785 even when some of its memory has uncorrected errors. This requires 786 special hardware support and typically ECC memory. 787 788config HWPOISON_INJECT 789 tristate "HWPoison pages injector" 790 depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS 791 select PROC_PAGE_MONITOR 792 793config NOMMU_INITIAL_TRIM_EXCESS 794 int "Turn on mmap() excess space trimming before booting" 795 depends on !MMU 796 default 1 797 help 798 The NOMMU mmap() frequently needs to allocate large contiguous chunks 799 of memory on which to store mappings, but it can only ask the system 800 allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently 801 more than it requires. To deal with this, mmap() is able to trim off 802 the excess and return it to the allocator. 803 804 If trimming is enabled, the excess is trimmed off and returned to the 805 system allocator, which can cause extra fragmentation, particularly 806 if there are a lot of transient processes. 807 808 If trimming is disabled, the excess is kept, but not used, which for 809 long-term mappings means that the space is wasted. 810 811 Trimming can be dynamically controlled through a sysctl option 812 (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of 813 excess pages there must be before trimming should occur, or zero if 814 no trimming is to occur. 815 816 This option specifies the initial value of this option. The default 817 of 1 says that all excess pages should be trimmed. 818 819 See Documentation/admin-guide/mm/nommu-mmap.rst for more information. 820 821config ARCH_WANT_GENERAL_HUGETLB 822 bool 823 824config ARCH_WANTS_THP_SWAP 825 def_bool n 826 827config PERSISTENT_HUGE_ZERO_FOLIO 828 bool "Allocate a PMD sized folio for zeroing" 829 depends on TRANSPARENT_HUGEPAGE 830 help 831 Enable this option to reduce the runtime refcounting overhead 832 of the huge zero folio and expand the places in the kernel 833 that can use huge zero folios. For instance, block I/O benefits 834 from access to large folios for zeroing memory. 835 836 With this option enabled, the huge zero folio is allocated 837 once and never freed. One full huge page's worth of memory shall 838 be used. 839 840 Say Y if your system has lots of memory. Say N if you are 841 memory constrained. 842 843config MM_ID 844 def_bool n 845 846menuconfig TRANSPARENT_HUGEPAGE 847 bool "Transparent Hugepage Support" 848 depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE && !PREEMPT_RT 849 select COMPACTION 850 select XARRAY_MULTI 851 select MM_ID 852 help 853 Transparent Hugepages allows the kernel to use huge pages and 854 huge tlb transparently to the applications whenever possible. 855 This feature can improve computing performance to certain 856 applications by speeding up page faults during memory 857 allocation, by reducing the number of tlb misses and by speeding 858 up the pagetable walking. 859 860 If memory constrained on embedded, you may want to say N. 861 862if TRANSPARENT_HUGEPAGE 863 864choice 865 prompt "Transparent Hugepage Support sysfs defaults" 866 depends on TRANSPARENT_HUGEPAGE 867 default TRANSPARENT_HUGEPAGE_ALWAYS 868 help 869 Selects the sysfs defaults for Transparent Hugepage Support. 870 871 config TRANSPARENT_HUGEPAGE_ALWAYS 872 bool "always" 873 help 874 Enabling Transparent Hugepage always, can increase the 875 memory footprint of applications without a guaranteed 876 benefit but it will work automatically for all applications. 877 878 config TRANSPARENT_HUGEPAGE_MADVISE 879 bool "madvise" 880 help 881 Enabling Transparent Hugepage madvise, will only provide a 882 performance improvement benefit to the applications using 883 madvise(MADV_HUGEPAGE) but it won't risk to increase the 884 memory footprint of applications without a guaranteed 885 benefit. 886 887 config TRANSPARENT_HUGEPAGE_NEVER 888 bool "never" 889 help 890 Disable Transparent Hugepage by default. It can still be 891 enabled at runtime via sysfs. 892endchoice 893 894choice 895 prompt "Shmem hugepage allocation defaults" 896 depends on TRANSPARENT_HUGEPAGE 897 default TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER 898 help 899 Selects the hugepage allocation policy defaults for 900 the internal shmem mount. 901 902 The selection made here can be overridden by using the kernel 903 command line 'transparent_hugepage_shmem=' option. 904 905 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER 906 bool "never" 907 help 908 Disable hugepage allocation for shmem mount by default. It can 909 still be enabled with the kernel command line 910 'transparent_hugepage_shmem=' option or at runtime via sysfs 911 knob. Note that madvise(MADV_COLLAPSE) can still cause 912 transparent huge pages to be obtained even if this mode is 913 specified. 914 915 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ALWAYS 916 bool "always" 917 help 918 Always attempt to allocate hugepage for shmem mount, can 919 increase the memory footprint of applications without a 920 guaranteed benefit but it will work automatically for all 921 applications. 922 923 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_WITHIN_SIZE 924 bool "within_size" 925 help 926 Enable hugepage allocation for shmem mount if the allocation 927 will be fully within the i_size. This configuration also takes 928 into account any madvise(MADV_HUGEPAGE) hints that may be 929 provided by the applications. 930 931 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ADVISE 932 bool "advise" 933 help 934 Enable hugepage allocation for the shmem mount exclusively when 935 applications supply the madvise(MADV_HUGEPAGE) hint. 936 This ensures that hugepages are used only in response to explicit 937 requests from applications. 938endchoice 939 940choice 941 prompt "Tmpfs hugepage allocation defaults" 942 depends on TRANSPARENT_HUGEPAGE 943 default TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER 944 help 945 Selects the hugepage allocation policy defaults for 946 the tmpfs mount. 947 948 The selection made here can be overridden by using the kernel 949 command line 'transparent_hugepage_tmpfs=' option. 950 951 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER 952 bool "never" 953 help 954 Disable hugepage allocation for tmpfs mount by default. It can 955 still be enabled with the kernel command line 956 'transparent_hugepage_tmpfs=' option. Note that 957 madvise(MADV_COLLAPSE) can still cause transparent huge pages 958 to be obtained even if this mode is specified. 959 960 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ALWAYS 961 bool "always" 962 help 963 Always attempt to allocate hugepage for tmpfs mount, can 964 increase the memory footprint of applications without a 965 guaranteed benefit but it will work automatically for all 966 applications. 967 968 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_WITHIN_SIZE 969 bool "within_size" 970 help 971 Enable hugepage allocation for tmpfs mount if the allocation 972 will be fully within the i_size. This configuration also takes 973 into account any madvise(MADV_HUGEPAGE) hints that may be 974 provided by the applications. 975 976 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ADVISE 977 bool "advise" 978 help 979 Enable hugepage allocation for the tmpfs mount exclusively when 980 applications supply the madvise(MADV_HUGEPAGE) hint. 981 This ensures that hugepages are used only in response to explicit 982 requests from applications. 983endchoice 984 985config THP_SWAP 986 def_bool y 987 depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP && 64BIT 988 help 989 Swap transparent huge pages in one piece, without splitting. 990 XXX: For now, swap cluster backing transparent huge page 991 will be split after swapout. 992 993 For selection by architectures with reasonable THP sizes. 994 995config READ_ONLY_THP_FOR_FS 996 bool "Read-only THP for filesystems (EXPERIMENTAL)" 997 depends on TRANSPARENT_HUGEPAGE 998 999 help 1000 Allow khugepaged to put read-only file-backed pages in THP. 1001 1002 This is marked experimental because it is a new feature. Write 1003 support of file THPs will be developed in the next few release 1004 cycles. 1005 1006config NO_PAGE_MAPCOUNT 1007 bool "No per-page mapcount (EXPERIMENTAL)" 1008 help 1009 Do not maintain per-page mapcounts for pages part of larger 1010 allocations, such as transparent huge pages. 1011 1012 When this config option is enabled, some interfaces that relied on 1013 this information will rely on less-precise per-allocation information 1014 instead: for example, using the average per-page mapcount in such 1015 a large allocation instead of the per-page mapcount. 1016 1017 EXPERIMENTAL because the impact of some changes is still unclear. 1018 1019endif # TRANSPARENT_HUGEPAGE 1020 1021# simple helper to make the code a bit easier to read 1022config PAGE_MAPCOUNT 1023 def_bool !NO_PAGE_MAPCOUNT 1024 1025# 1026# The architecture supports pgtable leaves that is larger than PAGE_SIZE 1027# 1028config PGTABLE_HAS_HUGE_LEAVES 1029 def_bool TRANSPARENT_HUGEPAGE || HUGETLB_PAGE 1030 1031# 1032# We can end up creating gigantic folio. 1033# 1034config HAVE_GIGANTIC_FOLIOS 1035 def_bool (HUGETLB_PAGE && ARCH_HAS_GIGANTIC_PAGE) || \ 1036 (ZONE_DEVICE && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD) 1037 1038config ASYNC_KERNEL_PGTABLE_FREE 1039 def_bool n 1040 1041# TODO: Allow to be enabled without THP 1042config ARCH_SUPPORTS_HUGE_PFNMAP 1043 def_bool n 1044 depends on TRANSPARENT_HUGEPAGE 1045 1046config ARCH_SUPPORTS_PMD_PFNMAP 1047 def_bool y 1048 depends on ARCH_SUPPORTS_HUGE_PFNMAP && HAVE_ARCH_TRANSPARENT_HUGEPAGE 1049 1050config ARCH_SUPPORTS_PUD_PFNMAP 1051 def_bool y 1052 depends on ARCH_SUPPORTS_HUGE_PFNMAP && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD 1053 1054# 1055# Architectures that always use weak definitions for percpu 1056# variables in modules should set this. 1057# 1058config ARCH_MODULE_NEEDS_WEAK_PER_CPU 1059 bool 1060 1061# 1062# UP and nommu archs use km based percpu allocator 1063# 1064config NEED_PER_CPU_KM 1065 depends on !SMP || !MMU 1066 bool 1067 default y 1068 1069config NEED_PER_CPU_EMBED_FIRST_CHUNK 1070 bool 1071 1072config NEED_PER_CPU_PAGE_FIRST_CHUNK 1073 bool 1074 1075config USE_PERCPU_NUMA_NODE_ID 1076 bool 1077 1078config HAVE_SETUP_PER_CPU_AREA 1079 bool 1080 1081config CMA 1082 bool "Contiguous Memory Allocator" 1083 depends on MMU 1084 select MIGRATION 1085 select MEMORY_ISOLATION 1086 help 1087 This enables the Contiguous Memory Allocator which allows other 1088 subsystems to allocate big physically-contiguous blocks of memory. 1089 CMA reserves a region of memory and allows only movable pages to 1090 be allocated from it. This way, the kernel can use the memory for 1091 pagecache and when a subsystem requests for contiguous area, the 1092 allocated pages are migrated away to serve the contiguous request. 1093 1094 If unsure, say "n". 1095 1096config CMA_DEBUGFS 1097 bool "CMA debugfs interface" 1098 depends on CMA && DEBUG_FS 1099 help 1100 Turns on the DebugFS interface for CMA. 1101 1102config CMA_SYSFS 1103 bool "CMA information through sysfs interface" 1104 depends on CMA && SYSFS 1105 help 1106 This option exposes some sysfs attributes to get information 1107 from CMA. 1108 1109config CMA_AREAS 1110 int "Maximum count of the CMA areas" 1111 depends on CMA 1112 default 20 if NUMA 1113 default 8 1114 help 1115 CMA allows to create CMA areas for particular purpose, mainly, 1116 used as device private area. This parameter sets the maximum 1117 number of CMA area in the system. 1118 1119 If unsure, leave the default value "8" in UMA and "20" in NUMA. 1120 1121# 1122# Select this config option from the architecture Kconfig, if available, to set 1123# the max page order for physically contiguous allocations. 1124# 1125config ARCH_FORCE_MAX_ORDER 1126 int 1127 1128# 1129# When ARCH_FORCE_MAX_ORDER is not defined, 1130# the default page block order is MAX_PAGE_ORDER (10) as per 1131# include/linux/mmzone.h. 1132# 1133config PAGE_BLOCK_MAX_ORDER 1134 int "Page Block Order Upper Limit" 1135 range 1 10 if ARCH_FORCE_MAX_ORDER = 0 1136 default 10 if ARCH_FORCE_MAX_ORDER = 0 1137 range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0 1138 default ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0 1139 help 1140 The page block order refers to the power of two number of pages that 1141 are physically contiguous and can have a migrate type associated to 1142 them. The maximum size of the page block order is at least limited by 1143 ARCH_FORCE_MAX_ORDER/MAX_PAGE_ORDER. 1144 1145 This config adds a new upper limit of default page block 1146 order when the page block order is required to be smaller than 1147 ARCH_FORCE_MAX_ORDER/MAX_PAGE_ORDER or other limits 1148 (see include/linux/pageblock-flags.h for details). 1149 1150 Reducing pageblock order can negatively impact THP generation 1151 success rate. If your workloads use THP heavily, please use this 1152 option with caution. 1153 1154 Don't change if unsure. 1155 1156config MEM_SOFT_DIRTY 1157 bool "Track memory changes" 1158 depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS 1159 select PROC_PAGE_MONITOR 1160 help 1161 This option enables memory changes tracking by introducing a 1162 soft-dirty bit on pte-s. This bit it set when someone writes 1163 into a page just as regular dirty bit, but unlike the latter 1164 it can be cleared by hands. 1165 1166 See Documentation/admin-guide/mm/soft-dirty.rst for more details. 1167 1168config GENERIC_EARLY_IOREMAP 1169 bool 1170 1171config STACK_MAX_DEFAULT_SIZE_MB 1172 int "Default maximum user stack size for 32-bit processes (MB)" 1173 default 100 1174 range 8 2048 1175 depends on STACK_GROWSUP && (!64BIT || COMPAT) 1176 help 1177 This is the maximum stack size in Megabytes in the VM layout of 32-bit 1178 user processes when the stack grows upwards (currently only on parisc 1179 arch) when the RLIMIT_STACK hard limit is unlimited. 1180 1181 A sane initial value is 100 MB. 1182 1183config DEFERRED_STRUCT_PAGE_INIT 1184 bool "Defer initialisation of struct pages to kthreads" 1185 depends on SPARSEMEM 1186 depends on !NEED_PER_CPU_KM 1187 depends on 64BIT 1188 depends on !KMSAN 1189 select PADATA 1190 help 1191 Ordinarily all struct pages are initialised during early boot in a 1192 single thread. On very large machines this can take a considerable 1193 amount of time. If this option is set, large machines will bring up 1194 a subset of memmap at boot and then initialise the rest in parallel. 1195 This has a potential performance impact on tasks running early in the 1196 lifetime of the system until these kthreads finish the 1197 initialisation. 1198 1199config PAGE_IDLE_FLAG 1200 bool 1201 select PAGE_EXTENSION if !64BIT 1202 help 1203 This adds PG_idle and PG_young flags to 'struct page'. PTE Accessed 1204 bit writers can set the state of the bit in the flags so that PTE 1205 Accessed bit readers may avoid disturbance. 1206 1207config IDLE_PAGE_TRACKING 1208 bool "Enable idle page tracking" 1209 depends on SYSFS && MMU 1210 select PAGE_IDLE_FLAG 1211 help 1212 This feature allows to estimate the amount of user pages that have 1213 not been touched during a given period of time. This information can 1214 be useful to tune memory cgroup limits and/or for job placement 1215 within a compute cluster. 1216 1217 See Documentation/admin-guide/mm/idle_page_tracking.rst for 1218 more details. 1219 1220# Architectures which implement cpu_dcache_is_aliasing() to query 1221# whether the data caches are aliased (VIVT or VIPT with dcache 1222# aliasing) need to select this. 1223config ARCH_HAS_CPU_CACHE_ALIASING 1224 bool 1225 1226config ARCH_HAS_CACHE_LINE_SIZE 1227 bool 1228 1229config ARCH_HAS_CURRENT_STACK_POINTER 1230 bool 1231 help 1232 In support of HARDENED_USERCOPY performing stack variable lifetime 1233 checking, an architecture-agnostic way to find the stack pointer 1234 is needed. Once an architecture defines an unsigned long global 1235 register alias named "current_stack_pointer", this config can be 1236 selected. 1237 1238config ARCH_HAS_ZONE_DMA_SET 1239 bool 1240 1241config ZONE_DMA 1242 bool "Support DMA zone" if ARCH_HAS_ZONE_DMA_SET 1243 default y if ARM64 || X86 1244 1245config ZONE_DMA32 1246 bool "Support DMA32 zone" if ARCH_HAS_ZONE_DMA_SET 1247 depends on !X86_32 1248 default y if ARM64 1249 1250config ZONE_DEVICE 1251 bool "Device memory (pmem, HMM, etc...) hotplug support" 1252 depends on MEMORY_HOTPLUG 1253 depends on MEMORY_HOTREMOVE 1254 depends on SPARSEMEM_VMEMMAP 1255 select XARRAY_MULTI 1256 1257 help 1258 Device memory hotplug support allows for establishing pmem, 1259 or other device driver discovered memory regions, in the 1260 memmap. This allows pfn_to_page() lookups of otherwise 1261 "device-physical" addresses which is needed for DAX, PCI_P2PDMA, and 1262 DEVICE_PRIVATE features among others. 1263 1264 Enabling this option will reduce the entropy of x86 KASLR memory 1265 regions. For example - on a 46 bit system, the entropy goes down 1266 from 16 bits to 15 bits. The actual reduction in entropy depends 1267 on the physical address bits, on processor features, kernel config 1268 (5 level page table) and physical memory present on the system. 1269 1270# 1271# Helpers to mirror range of the CPU page tables of a process into device page 1272# tables. 1273# 1274config HMM_MIRROR 1275 bool 1276 depends on MMU 1277 1278config GET_FREE_REGION 1279 bool 1280 1281config DEVICE_PRIVATE 1282 bool "Unaddressable device memory (GPU memory, ...)" 1283 depends on ZONE_DEVICE 1284 select GET_FREE_REGION 1285 1286 help 1287 Allows creation of struct pages to represent unaddressable device 1288 memory; i.e., memory that is only accessible from the device (or 1289 group of devices). You likely also want to select HMM_MIRROR. 1290 1291config VMAP_PFN 1292 bool 1293 1294config ARCH_USES_HIGH_VMA_FLAGS 1295 bool 1296config ARCH_HAS_PKEYS 1297 bool 1298 1299config ARCH_USES_PG_ARCH_2 1300 bool 1301config ARCH_USES_PG_ARCH_3 1302 bool 1303 1304config VM_EVENT_COUNTERS 1305 default y 1306 bool "Enable VM event counters for /proc/vmstat" if EXPERT 1307 help 1308 VM event counters are needed for event counts to be shown. 1309 This option allows the disabling of the VM event counters 1310 on EXPERT systems. /proc/vmstat will only show page counts 1311 if VM event counters are disabled. 1312 1313config PERCPU_STATS 1314 bool "Collect percpu memory statistics" 1315 help 1316 This feature collects and exposes statistics via debugfs. The 1317 information includes global and per chunk statistics, which can 1318 be used to help understand percpu memory usage. 1319 1320config GUP_TEST 1321 bool "Enable infrastructure for get_user_pages()-related unit tests" 1322 depends on DEBUG_FS 1323 help 1324 Provides /sys/kernel/debug/gup_test, which in turn provides a way 1325 to make ioctl calls that can launch kernel-based unit tests for 1326 the get_user_pages*() and pin_user_pages*() family of API calls. 1327 1328 These tests include benchmark testing of the _fast variants of 1329 get_user_pages*() and pin_user_pages*(), as well as smoke tests of 1330 the non-_fast variants. 1331 1332 There is also a sub-test that allows running dump_page() on any 1333 of up to eight pages (selected by command line args) within the 1334 range of user-space addresses. These pages are either pinned via 1335 pin_user_pages*(), or pinned via get_user_pages*(), as specified 1336 by other command line arguments. 1337 1338 See tools/testing/selftests/mm/gup_test.c 1339 1340comment "GUP_TEST needs to have DEBUG_FS enabled" 1341 depends on !GUP_TEST && !DEBUG_FS 1342 1343config GUP_GET_PXX_LOW_HIGH 1344 bool 1345 1346config DMAPOOL_TEST 1347 tristate "Enable a module to run time tests on dma_pool" 1348 depends on HAS_DMA 1349 help 1350 Provides a test module that will allocate and free many blocks of 1351 various sizes and report how long it takes. This is intended to 1352 provide a consistent way to measure how changes to the 1353 dma_pool_alloc/free routines affect performance. 1354 1355config ARCH_HAS_PTE_SPECIAL 1356 bool 1357 1358config MAPPING_DIRTY_HELPERS 1359 bool 1360 1361config KMAP_LOCAL 1362 bool 1363 1364config KMAP_LOCAL_NON_LINEAR_PTE_ARRAY 1365 bool 1366 1367config MEMFD_CREATE 1368 bool "Enable memfd_create() system call" if EXPERT 1369 1370config SECRETMEM 1371 default y 1372 bool "Enable memfd_secret() system call" if EXPERT 1373 depends on ARCH_HAS_SET_DIRECT_MAP 1374 help 1375 Enable the memfd_secret() system call with the ability to create 1376 memory areas visible only in the context of the owning process and 1377 not mapped to other processes and other kernel page tables. 1378 1379config ANON_VMA_NAME 1380 bool "Anonymous VMA name support" 1381 depends on PROC_FS && ADVISE_SYSCALLS && MMU 1382 1383 help 1384 Allow naming anonymous virtual memory areas. 1385 1386 This feature allows assigning names to virtual memory areas. Assigned 1387 names can be later retrieved from /proc/pid/maps and /proc/pid/smaps 1388 and help identifying individual anonymous memory areas. 1389 Assigning a name to anonymous virtual memory area might prevent that 1390 area from being merged with adjacent virtual memory areas due to the 1391 difference in their name. 1392 1393config HAVE_ARCH_USERFAULTFD_WP 1394 bool 1395 help 1396 Arch has userfaultfd write protection support 1397 1398config HAVE_ARCH_USERFAULTFD_MINOR 1399 bool 1400 help 1401 Arch has userfaultfd minor fault support 1402 1403menuconfig USERFAULTFD 1404 bool "Enable userfaultfd() system call" 1405 depends on MMU 1406 help 1407 Enable the userfaultfd() system call that allows to intercept and 1408 handle page faults in userland. 1409 1410if USERFAULTFD 1411config PTE_MARKER_UFFD_WP 1412 bool "Userfaultfd write protection support for shmem/hugetlbfs" 1413 default y 1414 depends on HAVE_ARCH_USERFAULTFD_WP 1415 1416 help 1417 Allows to create marker PTEs for userfaultfd write protection 1418 purposes. It is required to enable userfaultfd write protection on 1419 file-backed memory types like shmem and hugetlbfs. 1420endif # USERFAULTFD 1421 1422# multi-gen LRU { 1423config LRU_GEN 1424 bool "Multi-Gen LRU" 1425 depends on MMU 1426 # make sure folio->flags has enough spare bits 1427 depends on 64BIT || !SPARSEMEM || SPARSEMEM_VMEMMAP 1428 help 1429 A high performance LRU implementation to overcommit memory. See 1430 Documentation/admin-guide/mm/multigen_lru.rst for details. 1431 1432config LRU_GEN_ENABLED 1433 bool "Enable by default" 1434 depends on LRU_GEN 1435 help 1436 This option enables the multi-gen LRU by default. 1437 1438config LRU_GEN_STATS 1439 bool "Full stats for debugging" 1440 depends on LRU_GEN 1441 help 1442 Do not enable this option unless you plan to look at historical stats 1443 from evicted generations for debugging purpose. 1444 1445 This option has a per-memcg and per-node memory overhead. 1446 1447config LRU_GEN_WALKS_MMU 1448 def_bool y 1449 depends on LRU_GEN && ARCH_HAS_HW_PTE_YOUNG 1450# } 1451 1452config ARCH_SUPPORTS_PER_VMA_LOCK 1453 def_bool n 1454 1455config PER_VMA_LOCK 1456 def_bool y 1457 depends on ARCH_SUPPORTS_PER_VMA_LOCK && MMU && SMP 1458 help 1459 Allow per-vma locking during page fault handling. 1460 1461 This feature allows locking each virtual memory area separately when 1462 handling page faults instead of taking mmap_lock. 1463 1464config LOCK_MM_AND_FIND_VMA 1465 bool 1466 depends on !STACK_GROWSUP 1467 1468config IOMMU_MM_DATA 1469 bool 1470 1471config EXECMEM 1472 bool 1473 1474config NUMA_MEMBLKS 1475 bool 1476 1477config NUMA_EMU 1478 bool "NUMA emulation" 1479 depends on NUMA_MEMBLKS 1480 depends on X86 || GENERIC_ARCH_NUMA 1481 help 1482 Enable NUMA emulation. A flat machine will be split 1483 into virtual nodes when booted with "numa=fake=N", where N is the 1484 number of nodes. This is only useful for debugging. 1485 1486config ARCH_HAS_USER_SHADOW_STACK 1487 bool 1488 help 1489 The architecture has hardware support for userspace shadow call 1490 stacks (eg, x86 CET, arm64 GCS or RISC-V Zicfiss). 1491 1492config HAVE_ARCH_TLB_REMOVE_TABLE 1493 def_bool n 1494 1495config PT_RECLAIM 1496 def_bool y 1497 depends on MMU_GATHER_RCU_TABLE_FREE && !HAVE_ARCH_TLB_REMOVE_TABLE 1498 help 1499 Try to reclaim empty user page table pages in paths other than munmap 1500 and exit_mmap path. 1501 1502 Note: now only empty user PTE page table pages will be reclaimed. 1503 1504config FIND_NORMAL_PAGE 1505 def_bool n 1506 1507config ARCH_HAS_LAZY_MMU_MODE 1508 bool 1509 help 1510 The architecture uses the lazy MMU mode. This allows changes to 1511 MMU-related architectural state to be deferred until the mode is 1512 exited. See <linux/pgtable.h> for details. 1513 1514config LAZY_MMU_MODE_KUNIT_TEST 1515 tristate "KUnit tests for the lazy MMU mode" if !KUNIT_ALL_TESTS 1516 depends on ARCH_HAS_LAZY_MMU_MODE 1517 depends on KUNIT 1518 default KUNIT_ALL_TESTS 1519 help 1520 Enable this option to check that the lazy MMU mode interface behaves 1521 as expected. Only tests for the generic interface are included (not 1522 architecture-specific behaviours). 1523 1524 If unsure, say N. 1525 1526source "mm/damon/Kconfig" 1527 1528endmenu 1529