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 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 default TRANSPARENT_HUGEPAGE_ALWAYS 867 help 868 Selects the sysfs defaults for Transparent Hugepage Support. 869 870 config TRANSPARENT_HUGEPAGE_ALWAYS 871 bool "always" 872 help 873 Enabling Transparent Hugepage always, can increase the 874 memory footprint of applications without a guaranteed 875 benefit but it will work automatically for all applications. 876 877 config TRANSPARENT_HUGEPAGE_MADVISE 878 bool "madvise" 879 help 880 Enabling Transparent Hugepage madvise, will only provide a 881 performance improvement benefit to the applications using 882 madvise(MADV_HUGEPAGE) but it won't risk to increase the 883 memory footprint of applications without a guaranteed 884 benefit. 885 886 config TRANSPARENT_HUGEPAGE_NEVER 887 bool "never" 888 help 889 Disable Transparent Hugepage by default. It can still be 890 enabled at runtime via sysfs. 891endchoice 892 893choice 894 prompt "Shmem hugepage allocation defaults" 895 default TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER 896 help 897 Selects the hugepage allocation policy defaults for 898 the internal shmem mount. 899 900 The selection made here can be overridden by using the kernel 901 command line 'transparent_hugepage_shmem=' option. 902 903 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER 904 bool "never" 905 help 906 Disable hugepage allocation for shmem mount by default. It can 907 still be enabled with the kernel command line 908 'transparent_hugepage_shmem=' option or at runtime via sysfs 909 knob. Note that madvise(MADV_COLLAPSE) can still cause 910 transparent huge pages to be obtained even if this mode is 911 specified. 912 913 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ALWAYS 914 bool "always" 915 help 916 Always attempt to allocate hugepage for shmem mount, can 917 increase the memory footprint of applications without a 918 guaranteed benefit but it will work automatically for all 919 applications. 920 921 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_WITHIN_SIZE 922 bool "within_size" 923 help 924 Enable hugepage allocation for shmem mount if the allocation 925 will be fully within the i_size. This configuration also takes 926 into account any madvise(MADV_HUGEPAGE) hints that may be 927 provided by the applications. 928 929 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ADVISE 930 bool "advise" 931 help 932 Enable hugepage allocation for the shmem mount exclusively when 933 applications supply the madvise(MADV_HUGEPAGE) hint. 934 This ensures that hugepages are used only in response to explicit 935 requests from applications. 936endchoice 937 938choice 939 prompt "Tmpfs hugepage allocation defaults" 940 default TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER 941 help 942 Selects the hugepage allocation policy defaults for 943 the tmpfs mount. 944 945 The selection made here can be overridden by using the kernel 946 command line 'transparent_hugepage_tmpfs=' option. 947 948 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER 949 bool "never" 950 help 951 Disable hugepage allocation for tmpfs mount by default. It can 952 still be enabled with the kernel command line 953 'transparent_hugepage_tmpfs=' option. Note that 954 madvise(MADV_COLLAPSE) can still cause transparent huge pages 955 to be obtained even if this mode is specified. 956 957 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ALWAYS 958 bool "always" 959 help 960 Always attempt to allocate hugepage for tmpfs mount, can 961 increase the memory footprint of applications without a 962 guaranteed benefit but it will work automatically for all 963 applications. 964 965 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_WITHIN_SIZE 966 bool "within_size" 967 help 968 Enable hugepage allocation for tmpfs mount if the allocation 969 will be fully within the i_size. This configuration also takes 970 into account any madvise(MADV_HUGEPAGE) hints that may be 971 provided by the applications. 972 973 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ADVISE 974 bool "advise" 975 help 976 Enable hugepage allocation for the tmpfs mount exclusively when 977 applications supply the madvise(MADV_HUGEPAGE) hint. 978 This ensures that hugepages are used only in response to explicit 979 requests from applications. 980endchoice 981 982config THP_SWAP 983 def_bool y 984 depends on ARCH_WANTS_THP_SWAP && SWAP && 64BIT 985 help 986 Swap transparent huge pages in one piece, without splitting. 987 XXX: For now, swap cluster backing transparent huge page 988 will be split after swapout. 989 990 For selection by architectures with reasonable THP sizes. 991 992config NO_PAGE_MAPCOUNT 993 bool "No per-page mapcount (EXPERIMENTAL)" 994 help 995 Do not maintain per-page mapcounts for pages part of larger 996 allocations, such as transparent huge pages. 997 998 When this config option is enabled, some interfaces that relied on 999 this information will rely on less-precise per-allocation information 1000 instead: for example, using the average per-page mapcount in such 1001 a large allocation instead of the per-page mapcount. 1002 1003 EXPERIMENTAL because the impact of some changes is still unclear. 1004 1005endif # TRANSPARENT_HUGEPAGE 1006 1007# simple helper to make the code a bit easier to read 1008config PAGE_MAPCOUNT 1009 def_bool !NO_PAGE_MAPCOUNT 1010 1011# 1012# The architecture supports pgtable leaves that is larger than PAGE_SIZE 1013# 1014config PGTABLE_HAS_HUGE_LEAVES 1015 def_bool TRANSPARENT_HUGEPAGE || HUGETLB_PAGE 1016 1017# 1018# We can end up creating gigantic folio. 1019# 1020config HAVE_GIGANTIC_FOLIOS 1021 def_bool (HUGETLB_PAGE && ARCH_HAS_GIGANTIC_PAGE) || \ 1022 (ZONE_DEVICE && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD) 1023 1024config ASYNC_KERNEL_PGTABLE_FREE 1025 def_bool n 1026 1027# TODO: Allow to be enabled without THP 1028config ARCH_SUPPORTS_HUGE_PFNMAP 1029 def_bool n 1030 depends on TRANSPARENT_HUGEPAGE 1031 1032config ARCH_SUPPORTS_PMD_PFNMAP 1033 def_bool y 1034 depends on ARCH_SUPPORTS_HUGE_PFNMAP && HAVE_ARCH_TRANSPARENT_HUGEPAGE 1035 1036config ARCH_SUPPORTS_PUD_PFNMAP 1037 def_bool y 1038 depends on ARCH_SUPPORTS_HUGE_PFNMAP && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD 1039 1040# 1041# Architectures that always use weak definitions for percpu 1042# variables in modules should set this. 1043# 1044config ARCH_MODULE_NEEDS_WEAK_PER_CPU 1045 bool 1046 1047# 1048# UP and nommu archs use km based percpu allocator 1049# 1050config NEED_PER_CPU_KM 1051 depends on !SMP || !MMU 1052 bool 1053 default y 1054 1055config NEED_PER_CPU_EMBED_FIRST_CHUNK 1056 bool 1057 1058config NEED_PER_CPU_PAGE_FIRST_CHUNK 1059 bool 1060 1061config USE_PERCPU_NUMA_NODE_ID 1062 bool 1063 1064config HAVE_SETUP_PER_CPU_AREA 1065 bool 1066 1067config CMA 1068 bool "Contiguous Memory Allocator" 1069 depends on MMU 1070 select MIGRATION 1071 select MEMORY_ISOLATION 1072 help 1073 This enables the Contiguous Memory Allocator which allows other 1074 subsystems to allocate big physically-contiguous blocks of memory. 1075 CMA reserves a region of memory and allows only movable pages to 1076 be allocated from it. This way, the kernel can use the memory for 1077 pagecache and when a subsystem requests for contiguous area, the 1078 allocated pages are migrated away to serve the contiguous request. 1079 1080 If unsure, say "n". 1081 1082config CMA_DEBUGFS 1083 bool "CMA debugfs interface" 1084 depends on CMA && DEBUG_FS 1085 help 1086 Turns on the DebugFS interface for CMA. 1087 1088config CMA_SYSFS 1089 bool "CMA information through sysfs interface" 1090 depends on CMA && SYSFS 1091 help 1092 This option exposes some sysfs attributes to get information 1093 from CMA. 1094 1095config CMA_AREAS 1096 int "Maximum count of the CMA areas" 1097 depends on CMA 1098 default 20 if NUMA 1099 default 8 1100 help 1101 CMA allows to create CMA areas for particular purpose, mainly, 1102 used as device private area. This parameter sets the maximum 1103 number of CMA area in the system. 1104 1105 If unsure, leave the default value "8" in UMA and "20" in NUMA. 1106 1107# 1108# Select this config option from the architecture Kconfig, if available, to set 1109# the max page order for physically contiguous allocations. 1110# 1111config ARCH_FORCE_MAX_ORDER 1112 int 1113 1114# 1115# When ARCH_FORCE_MAX_ORDER is not defined, 1116# the default page block order is MAX_PAGE_ORDER (10) as per 1117# include/linux/mmzone.h. 1118# 1119config PAGE_BLOCK_MAX_ORDER 1120 int "Page Block Order Upper Limit" 1121 range 1 10 if ARCH_FORCE_MAX_ORDER = 0 1122 default 10 if ARCH_FORCE_MAX_ORDER = 0 1123 range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0 1124 default ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0 1125 help 1126 The page block order refers to the power of two number of pages that 1127 are physically contiguous and can have a migrate type associated to 1128 them. The maximum size of the page block order is at least limited by 1129 ARCH_FORCE_MAX_ORDER/MAX_PAGE_ORDER. 1130 1131 This config adds a new upper limit of default page block 1132 order when the page block order is required to be smaller than 1133 ARCH_FORCE_MAX_ORDER/MAX_PAGE_ORDER or other limits 1134 (see include/linux/pageblock-flags.h for details). 1135 1136 Reducing pageblock order can negatively impact THP generation 1137 success rate. If your workloads use THP heavily, please use this 1138 option with caution. 1139 1140 Don't change if unsure. 1141 1142config MEM_SOFT_DIRTY 1143 bool "Track memory changes" 1144 depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS 1145 select PROC_PAGE_MONITOR 1146 help 1147 This option enables memory changes tracking by introducing a 1148 soft-dirty bit on pte-s. This bit it set when someone writes 1149 into a page just as regular dirty bit, but unlike the latter 1150 it can be cleared by hands. 1151 1152 See Documentation/admin-guide/mm/soft-dirty.rst for more details. 1153 1154config GENERIC_EARLY_IOREMAP 1155 bool 1156 1157config STACK_MAX_DEFAULT_SIZE_MB 1158 int "Default maximum user stack size for 32-bit processes (MB)" 1159 default 100 1160 range 8 2048 1161 depends on STACK_GROWSUP && (!64BIT || COMPAT) 1162 help 1163 This is the maximum stack size in Megabytes in the VM layout of 32-bit 1164 user processes when the stack grows upwards (currently only on parisc 1165 arch) when the RLIMIT_STACK hard limit is unlimited. 1166 1167 A sane initial value is 100 MB. 1168 1169config DEFERRED_STRUCT_PAGE_INIT 1170 bool "Defer initialisation of struct pages to kthreads" 1171 depends on SPARSEMEM 1172 depends on !NEED_PER_CPU_KM 1173 depends on 64BIT 1174 depends on !KMSAN 1175 select PADATA 1176 help 1177 Ordinarily all struct pages are initialised during early boot in a 1178 single thread. On very large machines this can take a considerable 1179 amount of time. If this option is set, large machines will bring up 1180 a subset of memmap at boot and then initialise the rest in parallel. 1181 This has a potential performance impact on tasks running early in the 1182 lifetime of the system until these kthreads finish the 1183 initialisation. 1184 1185config PAGE_IDLE_FLAG 1186 bool 1187 select PAGE_EXTENSION if !64BIT 1188 help 1189 This adds PG_idle and PG_young flags to 'struct page'. PTE Accessed 1190 bit writers can set the state of the bit in the flags so that PTE 1191 Accessed bit readers may avoid disturbance. 1192 1193config IDLE_PAGE_TRACKING 1194 bool "Enable idle page tracking" 1195 depends on SYSFS && MMU 1196 select PAGE_IDLE_FLAG 1197 help 1198 This feature allows to estimate the amount of user pages that have 1199 not been touched during a given period of time. This information can 1200 be useful to tune memory cgroup limits and/or for job placement 1201 within a compute cluster. 1202 1203 See Documentation/admin-guide/mm/idle_page_tracking.rst for 1204 more details. 1205 1206# Architectures which implement cpu_dcache_is_aliasing() to query 1207# whether the data caches are aliased (VIVT or VIPT with dcache 1208# aliasing) need to select this. 1209config ARCH_HAS_CPU_CACHE_ALIASING 1210 bool 1211 1212config ARCH_HAS_CACHE_LINE_SIZE 1213 bool 1214 1215config ARCH_HAS_CURRENT_STACK_POINTER 1216 bool 1217 help 1218 In support of HARDENED_USERCOPY performing stack variable lifetime 1219 checking, an architecture-agnostic way to find the stack pointer 1220 is needed. Once an architecture defines an unsigned long global 1221 register alias named "current_stack_pointer", this config can be 1222 selected. 1223 1224config ARCH_HAS_ZONE_DMA_SET 1225 bool 1226 1227config ZONE_DMA 1228 bool "Support DMA zone" if ARCH_HAS_ZONE_DMA_SET 1229 default y if ARM64 || X86 1230 1231config ZONE_DMA32 1232 bool "Support DMA32 zone" if ARCH_HAS_ZONE_DMA_SET 1233 depends on !X86_32 1234 default y if ARM64 1235 1236config ZONE_DEVICE 1237 bool "Device memory (pmem, HMM, etc...) hotplug support" 1238 depends on MEMORY_HOTPLUG 1239 depends on MEMORY_HOTREMOVE 1240 depends on SPARSEMEM_VMEMMAP 1241 select XARRAY_MULTI 1242 1243 help 1244 Device memory hotplug support allows for establishing pmem, 1245 or other device driver discovered memory regions, in the 1246 memmap. This allows pfn_to_page() lookups of otherwise 1247 "device-physical" addresses which is needed for DAX, PCI_P2PDMA, and 1248 DEVICE_PRIVATE features among others. 1249 1250 Enabling this option will reduce the entropy of x86 KASLR memory 1251 regions. For example - on a 46 bit system, the entropy goes down 1252 from 16 bits to 15 bits. The actual reduction in entropy depends 1253 on the physical address bits, on processor features, kernel config 1254 (5 level page table) and physical memory present on the system. 1255 1256# 1257# Helpers to mirror range of the CPU page tables of a process into device page 1258# tables. 1259# 1260config HMM_MIRROR 1261 bool 1262 depends on MMU 1263 1264config GET_FREE_REGION 1265 bool 1266 1267config DEVICE_PRIVATE 1268 bool "Unaddressable device memory (GPU memory, ...)" 1269 depends on ZONE_DEVICE 1270 select GET_FREE_REGION 1271 1272 help 1273 Allows creation of struct pages to represent unaddressable device 1274 memory; i.e., memory that is only accessible from the device (or 1275 group of devices). You likely also want to select HMM_MIRROR. 1276 1277config VMAP_PFN 1278 bool 1279 1280config ARCH_USES_HIGH_VMA_FLAGS 1281 bool 1282config ARCH_HAS_PKEYS 1283 bool 1284 1285config ARCH_USES_PG_ARCH_2 1286 bool 1287config ARCH_USES_PG_ARCH_3 1288 bool 1289 1290config VM_EVENT_COUNTERS 1291 default y 1292 bool "Enable VM event counters for /proc/vmstat" if EXPERT 1293 help 1294 VM event counters are needed for event counts to be shown. 1295 This option allows the disabling of the VM event counters 1296 on EXPERT systems. /proc/vmstat will only show page counts 1297 if VM event counters are disabled. 1298 1299config PERCPU_STATS 1300 bool "Collect percpu memory statistics" 1301 help 1302 This feature collects and exposes statistics via debugfs. The 1303 information includes global and per chunk statistics, which can 1304 be used to help understand percpu memory usage. 1305 1306config GUP_TEST 1307 bool "Enable infrastructure for get_user_pages()-related unit tests" 1308 depends on DEBUG_FS 1309 help 1310 Provides /sys/kernel/debug/gup_test, which in turn provides a way 1311 to make ioctl calls that can launch kernel-based unit tests for 1312 the get_user_pages*() and pin_user_pages*() family of API calls. 1313 1314 These tests include benchmark testing of the _fast variants of 1315 get_user_pages*() and pin_user_pages*(), as well as smoke tests of 1316 the non-_fast variants. 1317 1318 There is also a sub-test that allows running dump_page() on any 1319 of up to eight pages (selected by command line args) within the 1320 range of user-space addresses. These pages are either pinned via 1321 pin_user_pages*(), or pinned via get_user_pages*(), as specified 1322 by other command line arguments. 1323 1324 See tools/testing/selftests/mm/gup_test.c 1325 1326comment "GUP_TEST needs to have DEBUG_FS enabled" 1327 depends on !GUP_TEST && !DEBUG_FS 1328 1329config GUP_GET_PXX_LOW_HIGH 1330 bool 1331 1332config DMAPOOL_TEST 1333 tristate "Enable a module to run time tests on dma_pool" 1334 depends on HAS_DMA 1335 help 1336 Provides a test module that will allocate and free many blocks of 1337 various sizes and report how long it takes. This is intended to 1338 provide a consistent way to measure how changes to the 1339 dma_pool_alloc/free routines affect performance. 1340 1341config ARCH_HAS_PTE_SPECIAL 1342 bool 1343 1344config MAPPING_DIRTY_HELPERS 1345 bool 1346 1347config KMAP_LOCAL 1348 bool 1349 1350config KMAP_LOCAL_NON_LINEAR_PTE_ARRAY 1351 bool 1352 1353config MEMFD_CREATE 1354 bool "Enable memfd_create() system call" if EXPERT 1355 1356config SECRETMEM 1357 default y 1358 bool "Enable memfd_secret() system call" if EXPERT 1359 depends on ARCH_HAS_SET_DIRECT_MAP 1360 help 1361 Enable the memfd_secret() system call with the ability to create 1362 memory areas visible only in the context of the owning process and 1363 not mapped to other processes and other kernel page tables. 1364 1365config ANON_VMA_NAME 1366 bool "Anonymous VMA name support" 1367 depends on PROC_FS && ADVISE_SYSCALLS && MMU 1368 1369 help 1370 Allow naming anonymous virtual memory areas. 1371 1372 This feature allows assigning names to virtual memory areas. Assigned 1373 names can be later retrieved from /proc/pid/maps and /proc/pid/smaps 1374 and help identifying individual anonymous memory areas. 1375 Assigning a name to anonymous virtual memory area might prevent that 1376 area from being merged with adjacent virtual memory areas due to the 1377 difference in their name. 1378 1379config HAVE_ARCH_USERFAULTFD_WP 1380 bool 1381 help 1382 Arch has userfaultfd write protection support 1383 1384config HAVE_ARCH_USERFAULTFD_MINOR 1385 bool 1386 help 1387 Arch has userfaultfd minor fault support 1388 1389menuconfig USERFAULTFD 1390 bool "Enable userfaultfd() system call" 1391 depends on MMU 1392 help 1393 Enable the userfaultfd() system call that allows to intercept and 1394 handle page faults in userland. 1395 1396if USERFAULTFD 1397config PTE_MARKER_UFFD_WP 1398 bool "Userfaultfd write protection support for shmem/hugetlbfs" 1399 default y 1400 depends on HAVE_ARCH_USERFAULTFD_WP 1401 1402 help 1403 Allows to create marker PTEs for userfaultfd write protection 1404 purposes. It is required to enable userfaultfd write protection on 1405 file-backed memory types like shmem and hugetlbfs. 1406endif # USERFAULTFD 1407 1408# multi-gen LRU { 1409config LRU_GEN 1410 bool "Multi-Gen LRU" 1411 depends on MMU 1412 # make sure folio->flags has enough spare bits 1413 depends on 64BIT || !SPARSEMEM || SPARSEMEM_VMEMMAP 1414 help 1415 A high performance LRU implementation to overcommit memory. See 1416 Documentation/admin-guide/mm/multigen_lru.rst for details. 1417 1418config LRU_GEN_ENABLED 1419 bool "Enable by default" 1420 depends on LRU_GEN 1421 help 1422 This option enables the multi-gen LRU by default. 1423 1424config LRU_GEN_STATS 1425 bool "Full stats for debugging" 1426 depends on LRU_GEN 1427 help 1428 Do not enable this option unless you plan to look at historical stats 1429 from evicted generations for debugging purpose. 1430 1431 This option has a per-memcg and per-node memory overhead. 1432 1433config LRU_GEN_WALKS_MMU 1434 def_bool y 1435 depends on LRU_GEN && ARCH_HAS_HW_PTE_YOUNG 1436# } 1437 1438config ARCH_SUPPORTS_PER_VMA_LOCK 1439 def_bool n 1440 1441config PER_VMA_LOCK 1442 def_bool y 1443 depends on ARCH_SUPPORTS_PER_VMA_LOCK && MMU && SMP 1444 help 1445 Allow per-vma locking during page fault handling. 1446 1447 This feature allows locking each virtual memory area separately when 1448 handling page faults instead of taking mmap_lock. 1449 1450config LOCK_MM_AND_FIND_VMA 1451 bool 1452 depends on !STACK_GROWSUP 1453 1454config IOMMU_MM_DATA 1455 bool 1456 1457config EXECMEM 1458 bool 1459 1460config NUMA_MEMBLKS 1461 bool 1462 1463config NUMA_EMU 1464 bool "NUMA emulation" 1465 depends on NUMA_MEMBLKS 1466 depends on X86 || GENERIC_ARCH_NUMA 1467 help 1468 Enable NUMA emulation. A flat machine will be split 1469 into virtual nodes when booted with "numa=fake=N", where N is the 1470 number of nodes. This is only useful for debugging. 1471 1472config ARCH_HAS_USER_SHADOW_STACK 1473 bool 1474 help 1475 The architecture has hardware support for userspace shadow call 1476 stacks (eg, x86 CET, arm64 GCS or RISC-V Zicfiss). 1477 1478config HAVE_ARCH_TLB_REMOVE_TABLE 1479 def_bool n 1480 1481config PT_RECLAIM 1482 def_bool y 1483 depends on MMU_GATHER_RCU_TABLE_FREE && !HAVE_ARCH_TLB_REMOVE_TABLE 1484 help 1485 Try to reclaim empty user page table pages in paths other than munmap 1486 and exit_mmap path. 1487 1488 Note: now only empty user PTE page table pages will be reclaimed. 1489 1490config FIND_NORMAL_PAGE 1491 def_bool n 1492 1493config ARCH_HAS_LAZY_MMU_MODE 1494 bool 1495 help 1496 The architecture uses the lazy MMU mode. This allows changes to 1497 MMU-related architectural state to be deferred until the mode is 1498 exited. See <linux/pgtable.h> for details. 1499 1500config LAZY_MMU_MODE_KUNIT_TEST 1501 tristate "KUnit tests for the lazy MMU mode" if !KUNIT_ALL_TESTS 1502 depends on ARCH_HAS_LAZY_MMU_MODE 1503 depends on KUNIT 1504 default KUNIT_ALL_TESTS 1505 help 1506 Enable this option to check that the lazy MMU mode interface behaves 1507 as expected. Only tests for the generic interface are included (not 1508 architecture-specific behaviours). 1509 1510 If unsure, say N. 1511 1512source "mm/damon/Kconfig" 1513 1514endmenu 1515