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