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