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 && HIGHMEM 287 help 288 Enable bounce buffers for devices that cannot access the full range of 289 memory available to the CPU. Enabled by default when HIGHMEM is 290 selected, but you may say n to override this. 291 292config VIRT_TO_BUS 293 bool 294 help 295 An architecture should select this if it implements the 296 deprecated interface virt_to_bus(). All new architectures 297 should probably not select this. 298 299 300config MMU_NOTIFIER 301 bool 302 select SRCU 303 select INTERVAL_TREE 304 305config KSM 306 bool "Enable KSM for page merging" 307 depends on MMU 308 select XXHASH 309 help 310 Enable Kernel Samepage Merging: KSM periodically scans those areas 311 of an application's address space that an app has advised may be 312 mergeable. When it finds pages of identical content, it replaces 313 the many instances by a single page with that content, so 314 saving memory until one or another app needs to modify the content. 315 Recommended for use with KVM, or with other duplicative applications. 316 See Documentation/vm/ksm.rst for more information: KSM is inactive 317 until a program has madvised that an area is MADV_MERGEABLE, and 318 root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set). 319 320config DEFAULT_MMAP_MIN_ADDR 321 int "Low address space to protect from user allocation" 322 depends on MMU 323 default 4096 324 help 325 This is the portion of low virtual memory which should be protected 326 from userspace allocation. Keeping a user from writing to low pages 327 can help reduce the impact of kernel NULL pointer bugs. 328 329 For most ia64, ppc64 and x86 users with lots of address space 330 a value of 65536 is reasonable and should cause no problems. 331 On arm and other archs it should not be higher than 32768. 332 Programs which use vm86 functionality or have some need to map 333 this low address space will need CAP_SYS_RAWIO or disable this 334 protection by setting the value to 0. 335 336 This value can be changed after boot using the 337 /proc/sys/vm/mmap_min_addr tunable. 338 339config ARCH_SUPPORTS_MEMORY_FAILURE 340 bool 341 342config MEMORY_FAILURE 343 depends on MMU 344 depends on ARCH_SUPPORTS_MEMORY_FAILURE 345 bool "Enable recovery from hardware memory errors" 346 select MEMORY_ISOLATION 347 select RAS 348 help 349 Enables code to recover from some memory failures on systems 350 with MCA recovery. This allows a system to continue running 351 even when some of its memory has uncorrected errors. This requires 352 special hardware support and typically ECC memory. 353 354config HWPOISON_INJECT 355 tristate "HWPoison pages injector" 356 depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS 357 select PROC_PAGE_MONITOR 358 359config NOMMU_INITIAL_TRIM_EXCESS 360 int "Turn on mmap() excess space trimming before booting" 361 depends on !MMU 362 default 1 363 help 364 The NOMMU mmap() frequently needs to allocate large contiguous chunks 365 of memory on which to store mappings, but it can only ask the system 366 allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently 367 more than it requires. To deal with this, mmap() is able to trim off 368 the excess and return it to the allocator. 369 370 If trimming is enabled, the excess is trimmed off and returned to the 371 system allocator, which can cause extra fragmentation, particularly 372 if there are a lot of transient processes. 373 374 If trimming is disabled, the excess is kept, but not used, which for 375 long-term mappings means that the space is wasted. 376 377 Trimming can be dynamically controlled through a sysctl option 378 (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of 379 excess pages there must be before trimming should occur, or zero if 380 no trimming is to occur. 381 382 This option specifies the initial value of this option. The default 383 of 1 says that all excess pages should be trimmed. 384 385 See Documentation/admin-guide/mm/nommu-mmap.rst for more information. 386 387config TRANSPARENT_HUGEPAGE 388 bool "Transparent Hugepage Support" 389 depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE 390 select COMPACTION 391 select XARRAY_MULTI 392 help 393 Transparent Hugepages allows the kernel to use huge pages and 394 huge tlb transparently to the applications whenever possible. 395 This feature can improve computing performance to certain 396 applications by speeding up page faults during memory 397 allocation, by reducing the number of tlb misses and by speeding 398 up the pagetable walking. 399 400 If memory constrained on embedded, you may want to say N. 401 402choice 403 prompt "Transparent Hugepage Support sysfs defaults" 404 depends on TRANSPARENT_HUGEPAGE 405 default TRANSPARENT_HUGEPAGE_ALWAYS 406 help 407 Selects the sysfs defaults for Transparent Hugepage Support. 408 409 config TRANSPARENT_HUGEPAGE_ALWAYS 410 bool "always" 411 help 412 Enabling Transparent Hugepage always, can increase the 413 memory footprint of applications without a guaranteed 414 benefit but it will work automatically for all applications. 415 416 config TRANSPARENT_HUGEPAGE_MADVISE 417 bool "madvise" 418 help 419 Enabling Transparent Hugepage madvise, will only provide a 420 performance improvement benefit to the applications using 421 madvise(MADV_HUGEPAGE) but it won't risk to increase the 422 memory footprint of applications without a guaranteed 423 benefit. 424endchoice 425 426config ARCH_WANTS_THP_SWAP 427 def_bool n 428 429config THP_SWAP 430 def_bool y 431 depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP 432 help 433 Swap transparent huge pages in one piece, without splitting. 434 XXX: For now, swap cluster backing transparent huge page 435 will be split after swapout. 436 437 For selection by architectures with reasonable THP sizes. 438 439# 440# UP and nommu archs use km based percpu allocator 441# 442config NEED_PER_CPU_KM 443 depends on !SMP 444 bool 445 default y 446 447config CLEANCACHE 448 bool "Enable cleancache driver to cache clean pages if tmem is present" 449 help 450 Cleancache can be thought of as a page-granularity victim cache 451 for clean pages that the kernel's pageframe replacement algorithm 452 (PFRA) would like to keep around, but can't since there isn't enough 453 memory. So when the PFRA "evicts" a page, it first attempts to use 454 cleancache code to put the data contained in that page into 455 "transcendent memory", memory that is not directly accessible or 456 addressable by the kernel and is of unknown and possibly 457 time-varying size. And when a cleancache-enabled 458 filesystem wishes to access a page in a file on disk, it first 459 checks cleancache to see if it already contains it; if it does, 460 the page is copied into the kernel and a disk access is avoided. 461 When a transcendent memory driver is available (such as zcache or 462 Xen transcendent memory), a significant I/O reduction 463 may be achieved. When none is available, all cleancache calls 464 are reduced to a single pointer-compare-against-NULL resulting 465 in a negligible performance hit. 466 467 If unsure, say Y to enable cleancache 468 469config FRONTSWAP 470 bool "Enable frontswap to cache swap pages if tmem is present" 471 depends on SWAP 472 help 473 Frontswap is so named because it can be thought of as the opposite 474 of a "backing" store for a swap device. The data is stored into 475 "transcendent memory", memory that is not directly accessible or 476 addressable by the kernel and is of unknown and possibly 477 time-varying size. When space in transcendent memory is available, 478 a significant swap I/O reduction may be achieved. When none is 479 available, all frontswap calls are reduced to a single pointer- 480 compare-against-NULL resulting in a negligible performance hit 481 and swap data is stored as normal on the matching swap device. 482 483 If unsure, say Y to enable frontswap. 484 485config CMA 486 bool "Contiguous Memory Allocator" 487 depends on MMU 488 select MIGRATION 489 select MEMORY_ISOLATION 490 help 491 This enables the Contiguous Memory Allocator which allows other 492 subsystems to allocate big physically-contiguous blocks of memory. 493 CMA reserves a region of memory and allows only movable pages to 494 be allocated from it. This way, the kernel can use the memory for 495 pagecache and when a subsystem requests for contiguous area, the 496 allocated pages are migrated away to serve the contiguous request. 497 498 If unsure, say "n". 499 500config CMA_DEBUG 501 bool "CMA debug messages (DEVELOPMENT)" 502 depends on DEBUG_KERNEL && CMA 503 help 504 Turns on debug messages in CMA. This produces KERN_DEBUG 505 messages for every CMA call as well as various messages while 506 processing calls such as dma_alloc_from_contiguous(). 507 This option does not affect warning and error messages. 508 509config CMA_DEBUGFS 510 bool "CMA debugfs interface" 511 depends on CMA && DEBUG_FS 512 help 513 Turns on the DebugFS interface for CMA. 514 515config CMA_AREAS 516 int "Maximum count of the CMA areas" 517 depends on CMA 518 default 19 if NUMA 519 default 7 520 help 521 CMA allows to create CMA areas for particular purpose, mainly, 522 used as device private area. This parameter sets the maximum 523 number of CMA area in the system. 524 525 If unsure, leave the default value "7" in UMA and "19" in NUMA. 526 527config MEM_SOFT_DIRTY 528 bool "Track memory changes" 529 depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS 530 select PROC_PAGE_MONITOR 531 help 532 This option enables memory changes tracking by introducing a 533 soft-dirty bit on pte-s. This bit it set when someone writes 534 into a page just as regular dirty bit, but unlike the latter 535 it can be cleared by hands. 536 537 See Documentation/admin-guide/mm/soft-dirty.rst for more details. 538 539config ZSWAP 540 bool "Compressed cache for swap pages (EXPERIMENTAL)" 541 depends on FRONTSWAP && CRYPTO=y 542 select ZPOOL 543 help 544 A lightweight compressed cache for swap pages. It takes 545 pages that are in the process of being swapped out and attempts to 546 compress them into a dynamically allocated RAM-based memory pool. 547 This can result in a significant I/O reduction on swap device and, 548 in the case where decompressing from RAM is faster that swap device 549 reads, can also improve workload performance. 550 551 This is marked experimental because it is a new feature (as of 552 v3.11) that interacts heavily with memory reclaim. While these 553 interactions don't cause any known issues on simple memory setups, 554 they have not be fully explored on the large set of potential 555 configurations and workloads that exist. 556 557choice 558 prompt "Compressed cache for swap pages default compressor" 559 depends on ZSWAP 560 default ZSWAP_COMPRESSOR_DEFAULT_LZO 561 help 562 Selects the default compression algorithm for the compressed cache 563 for swap pages. 564 565 For an overview what kind of performance can be expected from 566 a particular compression algorithm please refer to the benchmarks 567 available at the following LWN page: 568 https://lwn.net/Articles/751795/ 569 570 If in doubt, select 'LZO'. 571 572 The selection made here can be overridden by using the kernel 573 command line 'zswap.compressor=' option. 574 575config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE 576 bool "Deflate" 577 select CRYPTO_DEFLATE 578 help 579 Use the Deflate algorithm as the default compression algorithm. 580 581config ZSWAP_COMPRESSOR_DEFAULT_LZO 582 bool "LZO" 583 select CRYPTO_LZO 584 help 585 Use the LZO algorithm as the default compression algorithm. 586 587config ZSWAP_COMPRESSOR_DEFAULT_842 588 bool "842" 589 select CRYPTO_842 590 help 591 Use the 842 algorithm as the default compression algorithm. 592 593config ZSWAP_COMPRESSOR_DEFAULT_LZ4 594 bool "LZ4" 595 select CRYPTO_LZ4 596 help 597 Use the LZ4 algorithm as the default compression algorithm. 598 599config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC 600 bool "LZ4HC" 601 select CRYPTO_LZ4HC 602 help 603 Use the LZ4HC algorithm as the default compression algorithm. 604 605config ZSWAP_COMPRESSOR_DEFAULT_ZSTD 606 bool "zstd" 607 select CRYPTO_ZSTD 608 help 609 Use the zstd algorithm as the default compression algorithm. 610endchoice 611 612config ZSWAP_COMPRESSOR_DEFAULT 613 string 614 depends on ZSWAP 615 default "deflate" if ZSWAP_COMPRESSOR_DEFAULT_DEFLATE 616 default "lzo" if ZSWAP_COMPRESSOR_DEFAULT_LZO 617 default "842" if ZSWAP_COMPRESSOR_DEFAULT_842 618 default "lz4" if ZSWAP_COMPRESSOR_DEFAULT_LZ4 619 default "lz4hc" if ZSWAP_COMPRESSOR_DEFAULT_LZ4HC 620 default "zstd" if ZSWAP_COMPRESSOR_DEFAULT_ZSTD 621 default "" 622 623choice 624 prompt "Compressed cache for swap pages default allocator" 625 depends on ZSWAP 626 default ZSWAP_ZPOOL_DEFAULT_ZBUD 627 help 628 Selects the default allocator for the compressed cache for 629 swap pages. 630 The default is 'zbud' for compatibility, however please do 631 read the description of each of the allocators below before 632 making a right choice. 633 634 The selection made here can be overridden by using the kernel 635 command line 'zswap.zpool=' option. 636 637config ZSWAP_ZPOOL_DEFAULT_ZBUD 638 bool "zbud" 639 select ZBUD 640 help 641 Use the zbud allocator as the default allocator. 642 643config ZSWAP_ZPOOL_DEFAULT_Z3FOLD 644 bool "z3fold" 645 select Z3FOLD 646 help 647 Use the z3fold allocator as the default allocator. 648 649config ZSWAP_ZPOOL_DEFAULT_ZSMALLOC 650 bool "zsmalloc" 651 select ZSMALLOC 652 help 653 Use the zsmalloc allocator as the default allocator. 654endchoice 655 656config ZSWAP_ZPOOL_DEFAULT 657 string 658 depends on ZSWAP 659 default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD 660 default "z3fold" if ZSWAP_ZPOOL_DEFAULT_Z3FOLD 661 default "zsmalloc" if ZSWAP_ZPOOL_DEFAULT_ZSMALLOC 662 default "" 663 664config ZSWAP_DEFAULT_ON 665 bool "Enable the compressed cache for swap pages by default" 666 depends on ZSWAP 667 help 668 If selected, the compressed cache for swap pages will be enabled 669 at boot, otherwise it will be disabled. 670 671 The selection made here can be overridden by using the kernel 672 command line 'zswap.enabled=' option. 673 674config ZPOOL 675 tristate "Common API for compressed memory storage" 676 help 677 Compressed memory storage API. This allows using either zbud or 678 zsmalloc. 679 680config ZBUD 681 tristate "Low (Up to 2x) density storage for compressed pages" 682 help 683 A special purpose allocator for storing compressed pages. 684 It is designed to store up to two compressed pages per physical 685 page. While this design limits storage density, it has simple and 686 deterministic reclaim properties that make it preferable to a higher 687 density approach when reclaim will be used. 688 689config Z3FOLD 690 tristate "Up to 3x density storage for compressed pages" 691 depends on ZPOOL 692 help 693 A special purpose allocator for storing compressed pages. 694 It is designed to store up to three compressed pages per physical 695 page. It is a ZBUD derivative so the simplicity and determinism are 696 still there. 697 698config ZSMALLOC 699 tristate "Memory allocator for compressed pages" 700 depends on MMU 701 help 702 zsmalloc is a slab-based memory allocator designed to store 703 compressed RAM pages. zsmalloc uses virtual memory mapping 704 in order to reduce fragmentation. However, this results in a 705 non-standard allocator interface where a handle, not a pointer, is 706 returned by an alloc(). This handle must be mapped in order to 707 access the allocated space. 708 709config ZSMALLOC_STAT 710 bool "Export zsmalloc statistics" 711 depends on ZSMALLOC 712 select DEBUG_FS 713 help 714 This option enables code in the zsmalloc to collect various 715 statistics about what's happening in zsmalloc and exports that 716 information to userspace via debugfs. 717 If unsure, say N. 718 719config GENERIC_EARLY_IOREMAP 720 bool 721 722config STACK_MAX_DEFAULT_SIZE_MB 723 int "Default maximum user stack size for 32-bit processes (MB)" 724 default 100 725 range 8 2048 726 depends on STACK_GROWSUP && (!64BIT || COMPAT) 727 help 728 This is the maximum stack size in Megabytes in the VM layout of 32-bit 729 user processes when the stack grows upwards (currently only on parisc 730 arch) when the RLIMIT_STACK hard limit is unlimited. 731 732 A sane initial value is 100 MB. 733 734config DEFERRED_STRUCT_PAGE_INIT 735 bool "Defer initialisation of struct pages to kthreads" 736 depends on SPARSEMEM 737 depends on !NEED_PER_CPU_KM 738 depends on 64BIT 739 select PADATA 740 help 741 Ordinarily all struct pages are initialised during early boot in a 742 single thread. On very large machines this can take a considerable 743 amount of time. If this option is set, large machines will bring up 744 a subset of memmap at boot and then initialise the rest in parallel. 745 This has a potential performance impact on tasks running early in the 746 lifetime of the system until these kthreads finish the 747 initialisation. 748 749config IDLE_PAGE_TRACKING 750 bool "Enable idle page tracking" 751 depends on SYSFS && MMU 752 select PAGE_EXTENSION if !64BIT 753 help 754 This feature allows to estimate the amount of user pages that have 755 not been touched during a given period of time. This information can 756 be useful to tune memory cgroup limits and/or for job placement 757 within a compute cluster. 758 759 See Documentation/admin-guide/mm/idle_page_tracking.rst for 760 more details. 761 762config ARCH_HAS_PTE_DEVMAP 763 bool 764 765config ZONE_DEVICE 766 bool "Device memory (pmem, HMM, etc...) hotplug support" 767 depends on MEMORY_HOTPLUG 768 depends on MEMORY_HOTREMOVE 769 depends on SPARSEMEM_VMEMMAP 770 depends on ARCH_HAS_PTE_DEVMAP 771 select XARRAY_MULTI 772 773 help 774 Device memory hotplug support allows for establishing pmem, 775 or other device driver discovered memory regions, in the 776 memmap. This allows pfn_to_page() lookups of otherwise 777 "device-physical" addresses which is needed for using a DAX 778 mapping in an O_DIRECT operation, among other things. 779 780 If FS_DAX is enabled, then say Y. 781 782config DEV_PAGEMAP_OPS 783 bool 784 785# 786# Helpers to mirror range of the CPU page tables of a process into device page 787# tables. 788# 789config HMM_MIRROR 790 bool 791 depends on MMU 792 793config DEVICE_PRIVATE 794 bool "Unaddressable device memory (GPU memory, ...)" 795 depends on ZONE_DEVICE 796 select DEV_PAGEMAP_OPS 797 798 help 799 Allows creation of struct pages to represent unaddressable device 800 memory; i.e., memory that is only accessible from the device (or 801 group of devices). You likely also want to select HMM_MIRROR. 802 803config VMAP_PFN 804 bool 805 806config ARCH_USES_HIGH_VMA_FLAGS 807 bool 808config ARCH_HAS_PKEYS 809 bool 810 811config PERCPU_STATS 812 bool "Collect percpu memory statistics" 813 help 814 This feature collects and exposes statistics via debugfs. The 815 information includes global and per chunk statistics, which can 816 be used to help understand percpu memory usage. 817 818config GUP_TEST 819 bool "Enable infrastructure for get_user_pages()-related unit tests" 820 depends on DEBUG_FS 821 help 822 Provides /sys/kernel/debug/gup_test, which in turn provides a way 823 to make ioctl calls that can launch kernel-based unit tests for 824 the get_user_pages*() and pin_user_pages*() family of API calls. 825 826 These tests include benchmark testing of the _fast variants of 827 get_user_pages*() and pin_user_pages*(), as well as smoke tests of 828 the non-_fast variants. 829 830 There is also a sub-test that allows running dump_page() on any 831 of up to eight pages (selected by command line args) within the 832 range of user-space addresses. These pages are either pinned via 833 pin_user_pages*(), or pinned via get_user_pages*(), as specified 834 by other command line arguments. 835 836 See tools/testing/selftests/vm/gup_test.c 837 838comment "GUP_TEST needs to have DEBUG_FS enabled" 839 depends on !GUP_TEST && !DEBUG_FS 840 841config GUP_GET_PTE_LOW_HIGH 842 bool 843 844config READ_ONLY_THP_FOR_FS 845 bool "Read-only THP for filesystems (EXPERIMENTAL)" 846 depends on TRANSPARENT_HUGEPAGE && SHMEM 847 848 help 849 Allow khugepaged to put read-only file-backed pages in THP. 850 851 This is marked experimental because it is a new feature. Write 852 support of file THPs will be developed in the next few release 853 cycles. 854 855config ARCH_HAS_PTE_SPECIAL 856 bool 857 858# 859# Some architectures require a special hugepage directory format that is 860# required to support multiple hugepage sizes. For example a4fe3ce76 861# "powerpc/mm: Allow more flexible layouts for hugepage pagetables" 862# introduced it on powerpc. This allows for a more flexible hugepage 863# pagetable layouts. 864# 865config ARCH_HAS_HUGEPD 866 bool 867 868config MAPPING_DIRTY_HELPERS 869 bool 870 871config KMAP_LOCAL 872 bool 873 874endmenu 875