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