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