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