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