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