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