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