linux/mm/Kconfig
<<
>>
Prefs
   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
  99config HOLES_IN_ZONE
 100        bool
 101
 102# Don't discard allocated memory used to track "memory" and "reserved" memblocks
 103# after early boot, so it can still be used to test for validity of memory.
 104# Also, memblocks are updated with memory hot(un)plug.
 105config ARCH_KEEP_MEMBLOCK
 106        bool
 107
 108# Keep arch NUMA mapping infrastructure post-init.
 109config NUMA_KEEP_MEMINFO
 110        bool
 111
 112config MEMORY_ISOLATION
 113        bool
 114
 115#
 116# Only be set on architectures that have completely implemented memory hotplug
 117# feature. If you are not sure, don't touch it.
 118#
 119config HAVE_BOOTMEM_INFO_NODE
 120        def_bool n
 121
 122config ARCH_ENABLE_MEMORY_HOTPLUG
 123        bool
 124
 125# eventually, we can have this option just 'select SPARSEMEM'
 126config MEMORY_HOTPLUG
 127        bool "Allow for memory hot-add"
 128        select MEMORY_ISOLATION
 129        depends on SPARSEMEM || X86_64_ACPI_NUMA
 130        depends on ARCH_ENABLE_MEMORY_HOTPLUG
 131        depends on 64BIT || BROKEN
 132        select NUMA_KEEP_MEMINFO if NUMA
 133
 134config MEMORY_HOTPLUG_SPARSE
 135        def_bool y
 136        depends on SPARSEMEM && MEMORY_HOTPLUG
 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
 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
 432        bool
 433        default y
 434
 435config CLEANCACHE
 436        bool "Enable cleancache driver to cache clean pages if tmem is present"
 437        help
 438          Cleancache can be thought of as a page-granularity victim cache
 439          for clean pages that the kernel's pageframe replacement algorithm
 440          (PFRA) would like to keep around, but can't since there isn't enough
 441          memory.  So when the PFRA "evicts" a page, it first attempts to use
 442          cleancache code to put the data contained in that page into
 443          "transcendent memory", memory that is not directly accessible or
 444          addressable by the kernel and is of unknown and possibly
 445          time-varying size.  And when a cleancache-enabled
 446          filesystem wishes to access a page in a file on disk, it first
 447          checks cleancache to see if it already contains it; if it does,
 448          the page is copied into the kernel and a disk access is avoided.
 449          When a transcendent memory driver is available (such as zcache or
 450          Xen transcendent memory), a significant I/O reduction
 451          may be achieved.  When none is available, all cleancache calls
 452          are reduced to a single pointer-compare-against-NULL resulting
 453          in a negligible performance hit.
 454
 455          If unsure, say Y to enable cleancache
 456
 457config FRONTSWAP
 458        bool "Enable frontswap to cache swap pages if tmem is present"
 459        depends on SWAP
 460        help
 461          Frontswap is so named because it can be thought of as the opposite
 462          of a "backing" store for a swap device.  The data is stored into
 463          "transcendent memory", memory that is not directly accessible or
 464          addressable by the kernel and is of unknown and possibly
 465          time-varying size.  When space in transcendent memory is available,
 466          a significant swap I/O reduction may be achieved.  When none is
 467          available, all frontswap calls are reduced to a single pointer-
 468          compare-against-NULL resulting in a negligible performance hit
 469          and swap data is stored as normal on the matching swap device.
 470
 471          If unsure, say Y to enable frontswap.
 472
 473config CMA
 474        bool "Contiguous Memory Allocator"
 475        depends on MMU
 476        select MIGRATION
 477        select MEMORY_ISOLATION
 478        help
 479          This enables the Contiguous Memory Allocator which allows other
 480          subsystems to allocate big physically-contiguous blocks of memory.
 481          CMA reserves a region of memory and allows only movable pages to
 482          be allocated from it. This way, the kernel can use the memory for
 483          pagecache and when a subsystem requests for contiguous area, the
 484          allocated pages are migrated away to serve the contiguous request.
 485
 486          If unsure, say "n".
 487
 488config CMA_DEBUG
 489        bool "CMA debug messages (DEVELOPMENT)"
 490        depends on DEBUG_KERNEL && CMA
 491        help
 492          Turns on debug messages in CMA.  This produces KERN_DEBUG
 493          messages for every CMA call as well as various messages while
 494          processing calls such as dma_alloc_from_contiguous().
 495          This option does not affect warning and error messages.
 496
 497config CMA_DEBUGFS
 498        bool "CMA debugfs interface"
 499        depends on CMA && DEBUG_FS
 500        help
 501          Turns on the DebugFS interface for CMA.
 502
 503config CMA_SYSFS
 504        bool "CMA information through sysfs interface"
 505        depends on CMA && SYSFS
 506        help
 507          This option exposes some sysfs attributes to get information
 508          from CMA.
 509
 510config CMA_AREAS
 511        int "Maximum count of the CMA areas"
 512        depends on CMA
 513        default 19 if NUMA
 514        default 7
 515        help
 516          CMA allows to create CMA areas for particular purpose, mainly,
 517          used as device private area. This parameter sets the maximum
 518          number of CMA area in the system.
 519
 520          If unsure, leave the default value "7" in UMA and "19" in NUMA.
 521
 522config MEM_SOFT_DIRTY
 523        bool "Track memory changes"
 524        depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS
 525        select PROC_PAGE_MONITOR
 526        help
 527          This option enables memory changes tracking by introducing a
 528          soft-dirty bit on pte-s. This bit it set when someone writes
 529          into a page just as regular dirty bit, but unlike the latter
 530          it can be cleared by hands.
 531
 532          See Documentation/admin-guide/mm/soft-dirty.rst for more details.
 533
 534config ZSWAP
 535        bool "Compressed cache for swap pages (EXPERIMENTAL)"
 536        depends on FRONTSWAP && CRYPTO=y
 537        select ZPOOL
 538        help
 539          A lightweight compressed cache for swap pages.  It takes
 540          pages that are in the process of being swapped out and attempts to
 541          compress them into a dynamically allocated RAM-based memory pool.
 542          This can result in a significant I/O reduction on swap device and,
 543          in the case where decompressing from RAM is faster that swap device
 544          reads, can also improve workload performance.
 545
 546          This is marked experimental because it is a new feature (as of
 547          v3.11) that interacts heavily with memory reclaim.  While these
 548          interactions don't cause any known issues on simple memory setups,
 549          they have not be fully explored on the large set of potential
 550          configurations and workloads that exist.
 551
 552choice
 553        prompt "Compressed cache for swap pages default compressor"
 554        depends on ZSWAP
 555        default ZSWAP_COMPRESSOR_DEFAULT_LZO
 556        help
 557          Selects the default compression algorithm for the compressed cache
 558          for swap pages.
 559
 560          For an overview what kind of performance can be expected from
 561          a particular compression algorithm please refer to the benchmarks
 562          available at the following LWN page:
 563          https://lwn.net/Articles/751795/
 564
 565          If in doubt, select 'LZO'.
 566
 567          The selection made here can be overridden by using the kernel
 568          command line 'zswap.compressor=' option.
 569
 570config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE
 571        bool "Deflate"
 572        select CRYPTO_DEFLATE
 573        help
 574          Use the Deflate algorithm as the default compression algorithm.
 575
 576config ZSWAP_COMPRESSOR_DEFAULT_LZO
 577        bool "LZO"
 578        select CRYPTO_LZO
 579        help
 580          Use the LZO algorithm as the default compression algorithm.
 581
 582config ZSWAP_COMPRESSOR_DEFAULT_842
 583        bool "842"
 584        select CRYPTO_842
 585        help
 586          Use the 842 algorithm as the default compression algorithm.
 587
 588config ZSWAP_COMPRESSOR_DEFAULT_LZ4
 589        bool "LZ4"
 590        select CRYPTO_LZ4
 591        help
 592          Use the LZ4 algorithm as the default compression algorithm.
 593
 594config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC
 595        bool "LZ4HC"
 596        select CRYPTO_LZ4HC
 597        help
 598          Use the LZ4HC algorithm as the default compression algorithm.
 599
 600config ZSWAP_COMPRESSOR_DEFAULT_ZSTD
 601        bool "zstd"
 602        select CRYPTO_ZSTD
 603        help
 604          Use the zstd algorithm as the default compression algorithm.
 605endchoice
 606
 607config ZSWAP_COMPRESSOR_DEFAULT
 608       string
 609       depends on ZSWAP
 610       default "deflate" if ZSWAP_COMPRESSOR_DEFAULT_DEFLATE
 611       default "lzo" if ZSWAP_COMPRESSOR_DEFAULT_LZO
 612       default "842" if ZSWAP_COMPRESSOR_DEFAULT_842
 613       default "lz4" if ZSWAP_COMPRESSOR_DEFAULT_LZ4
 614       default "lz4hc" if ZSWAP_COMPRESSOR_DEFAULT_LZ4HC
 615       default "zstd" if ZSWAP_COMPRESSOR_DEFAULT_ZSTD
 616       default ""
 617
 618choice
 619        prompt "Compressed cache for swap pages default allocator"
 620        depends on ZSWAP
 621        default ZSWAP_ZPOOL_DEFAULT_ZBUD
 622        help
 623          Selects the default allocator for the compressed cache for
 624          swap pages.
 625          The default is 'zbud' for compatibility, however please do
 626          read the description of each of the allocators below before
 627          making a right choice.
 628
 629          The selection made here can be overridden by using the kernel
 630          command line 'zswap.zpool=' option.
 631
 632config ZSWAP_ZPOOL_DEFAULT_ZBUD
 633        bool "zbud"
 634        select ZBUD
 635        help
 636          Use the zbud allocator as the default allocator.
 637
 638config ZSWAP_ZPOOL_DEFAULT_Z3FOLD
 639        bool "z3fold"
 640        select Z3FOLD
 641        help
 642          Use the z3fold allocator as the default allocator.
 643
 644config ZSWAP_ZPOOL_DEFAULT_ZSMALLOC
 645        bool "zsmalloc"
 646        select ZSMALLOC
 647        help
 648          Use the zsmalloc allocator as the default allocator.
 649endchoice
 650
 651config ZSWAP_ZPOOL_DEFAULT
 652       string
 653       depends on ZSWAP
 654       default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD
 655       default "z3fold" if ZSWAP_ZPOOL_DEFAULT_Z3FOLD
 656       default "zsmalloc" if ZSWAP_ZPOOL_DEFAULT_ZSMALLOC
 657       default ""
 658
 659config ZSWAP_DEFAULT_ON
 660        bool "Enable the compressed cache for swap pages by default"
 661        depends on ZSWAP
 662        help
 663          If selected, the compressed cache for swap pages will be enabled
 664          at boot, otherwise it will be disabled.
 665
 666          The selection made here can be overridden by using the kernel
 667          command line 'zswap.enabled=' option.
 668
 669config ZPOOL
 670        tristate "Common API for compressed memory storage"
 671        help
 672          Compressed memory storage API.  This allows using either zbud or
 673          zsmalloc.
 674
 675config ZBUD
 676        tristate "Low (Up to 2x) density storage for compressed pages"
 677        depends on ZPOOL
 678        help
 679          A special purpose allocator for storing compressed pages.
 680          It is designed to store up to two compressed pages per physical
 681          page.  While this design limits storage density, it has simple and
 682          deterministic reclaim properties that make it preferable to a higher
 683          density approach when reclaim will be used.
 684
 685config Z3FOLD
 686        tristate "Up to 3x density storage for compressed pages"
 687        depends on ZPOOL
 688        help
 689          A special purpose allocator for storing compressed pages.
 690          It is designed to store up to three compressed pages per physical
 691          page. It is a ZBUD derivative so the simplicity and determinism are
 692          still there.
 693
 694config ZSMALLOC
 695        tristate "Memory allocator for compressed pages"
 696        depends on MMU
 697        help
 698          zsmalloc is a slab-based memory allocator designed to store
 699          compressed RAM pages.  zsmalloc uses virtual memory mapping
 700          in order to reduce fragmentation.  However, this results in a
 701          non-standard allocator interface where a handle, not a pointer, is
 702          returned by an alloc().  This handle must be mapped in order to
 703          access the allocated space.
 704
 705config ZSMALLOC_STAT
 706        bool "Export zsmalloc statistics"
 707        depends on ZSMALLOC
 708        select DEBUG_FS
 709        help
 710          This option enables code in the zsmalloc to collect various
 711          statistics about what's happening in zsmalloc and exports that
 712          information to userspace via debugfs.
 713          If unsure, say N.
 714
 715config GENERIC_EARLY_IOREMAP
 716        bool
 717
 718config STACK_MAX_DEFAULT_SIZE_MB
 719        int "Default maximum user stack size for 32-bit processes (MB)"
 720        default 100
 721        range 8 2048
 722        depends on STACK_GROWSUP && (!64BIT || COMPAT)
 723        help
 724          This is the maximum stack size in Megabytes in the VM layout of 32-bit
 725          user processes when the stack grows upwards (currently only on parisc
 726          arch) when the RLIMIT_STACK hard limit is unlimited.
 727
 728          A sane initial value is 100 MB.
 729
 730config DEFERRED_STRUCT_PAGE_INIT
 731        bool "Defer initialisation of struct pages to kthreads"
 732        depends on SPARSEMEM
 733        depends on !NEED_PER_CPU_KM
 734        depends on 64BIT
 735        select PADATA
 736        help
 737          Ordinarily all struct pages are initialised during early boot in a
 738          single thread. On very large machines this can take a considerable
 739          amount of time. If this option is set, large machines will bring up
 740          a subset of memmap at boot and then initialise the rest in parallel.
 741          This has a potential performance impact on tasks running early in the
 742          lifetime of the system until these kthreads finish the
 743          initialisation.
 744
 745config IDLE_PAGE_TRACKING
 746        bool "Enable idle page tracking"
 747        depends on SYSFS && MMU
 748        select PAGE_EXTENSION if !64BIT
 749        help
 750          This feature allows to estimate the amount of user pages that have
 751          not been touched during a given period of time. This information can
 752          be useful to tune memory cgroup limits and/or for job placement
 753          within a compute cluster.
 754
 755          See Documentation/admin-guide/mm/idle_page_tracking.rst for
 756          more details.
 757
 758config ARCH_HAS_CACHE_LINE_SIZE
 759        bool
 760
 761config ARCH_HAS_PTE_DEVMAP
 762        bool
 763
 764config ARCH_HAS_ZONE_DMA_SET
 765        bool
 766
 767config ZONE_DMA
 768        bool "Support DMA zone" if ARCH_HAS_ZONE_DMA_SET
 769        default y if ARM64 || X86
 770
 771config ZONE_DMA32
 772        bool "Support DMA32 zone" if ARCH_HAS_ZONE_DMA_SET
 773        depends on !X86_32
 774        default y if ARM64
 775
 776config ZONE_DEVICE
 777        bool "Device memory (pmem, HMM, etc...) hotplug support"
 778        depends on MEMORY_HOTPLUG
 779        depends on MEMORY_HOTREMOVE
 780        depends on SPARSEMEM_VMEMMAP
 781        depends on ARCH_HAS_PTE_DEVMAP
 782        select XARRAY_MULTI
 783
 784        help
 785          Device memory hotplug support allows for establishing pmem,
 786          or other device driver discovered memory regions, in the
 787          memmap. This allows pfn_to_page() lookups of otherwise
 788          "device-physical" addresses which is needed for using a DAX
 789          mapping in an O_DIRECT operation, among other things.
 790
 791          If FS_DAX is enabled, then say Y.
 792
 793config DEV_PAGEMAP_OPS
 794        bool
 795
 796#
 797# Helpers to mirror range of the CPU page tables of a process into device page
 798# tables.
 799#
 800config HMM_MIRROR
 801        bool
 802        depends on MMU
 803
 804config DEVICE_PRIVATE
 805        bool "Unaddressable device memory (GPU memory, ...)"
 806        depends on ZONE_DEVICE
 807        select DEV_PAGEMAP_OPS
 808
 809        help
 810          Allows creation of struct pages to represent unaddressable device
 811          memory; i.e., memory that is only accessible from the device (or
 812          group of devices). You likely also want to select HMM_MIRROR.
 813
 814config VMAP_PFN
 815        bool
 816
 817config ARCH_USES_HIGH_VMA_FLAGS
 818        bool
 819config ARCH_HAS_PKEYS
 820        bool
 821
 822config PERCPU_STATS
 823        bool "Collect percpu memory statistics"
 824        help
 825          This feature collects and exposes statistics via debugfs. The
 826          information includes global and per chunk statistics, which can
 827          be used to help understand percpu memory usage.
 828
 829config GUP_TEST
 830        bool "Enable infrastructure for get_user_pages()-related unit tests"
 831        depends on DEBUG_FS
 832        help
 833          Provides /sys/kernel/debug/gup_test, which in turn provides a way
 834          to make ioctl calls that can launch kernel-based unit tests for
 835          the get_user_pages*() and pin_user_pages*() family of API calls.
 836
 837          These tests include benchmark testing of the _fast variants of
 838          get_user_pages*() and pin_user_pages*(), as well as smoke tests of
 839          the non-_fast variants.
 840
 841          There is also a sub-test that allows running dump_page() on any
 842          of up to eight pages (selected by command line args) within the
 843          range of user-space addresses. These pages are either pinned via
 844          pin_user_pages*(), or pinned via get_user_pages*(), as specified
 845          by other command line arguments.
 846
 847          See tools/testing/selftests/vm/gup_test.c
 848
 849comment "GUP_TEST needs to have DEBUG_FS enabled"
 850        depends on !GUP_TEST && !DEBUG_FS
 851
 852config GUP_GET_PTE_LOW_HIGH
 853        bool
 854
 855config READ_ONLY_THP_FOR_FS
 856        bool "Read-only THP for filesystems (EXPERIMENTAL)"
 857        depends on TRANSPARENT_HUGEPAGE && SHMEM
 858
 859        help
 860          Allow khugepaged to put read-only file-backed pages in THP.
 861
 862          This is marked experimental because it is a new feature. Write
 863          support of file THPs will be developed in the next few release
 864          cycles.
 865
 866config ARCH_HAS_PTE_SPECIAL
 867        bool
 868
 869#
 870# Some architectures require a special hugepage directory format that is
 871# required to support multiple hugepage sizes. For example a4fe3ce76
 872# "powerpc/mm: Allow more flexible layouts for hugepage pagetables"
 873# introduced it on powerpc.  This allows for a more flexible hugepage
 874# pagetable layouts.
 875#
 876config ARCH_HAS_HUGEPD
 877        bool
 878
 879config MAPPING_DIRTY_HELPERS
 880        bool
 881
 882config KMAP_LOCAL
 883        bool
 884
 885# struct io_mapping based helper.  Selected by drivers that need them
 886config IO_MAPPING
 887        bool
 888
 889config SECRETMEM
 890        def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED
 891
 892endmenu
 893