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