mm/Kconfig

   1
   2 menu "Memory Management options"
   3
   4 config SELECT_MEMORY_MODEL
   5         def_bool y
   6         depends on ARCH_SELECT_MEMORY_MODEL
   7
   8 choice
   9         prompt "Memory model"
  10         depends on SELECT_MEMORY_MODEL
  11         default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT
  12         default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT
  13         default FLATMEM_MANUAL
  14
  15 config FLATMEM_MANUAL
  16         bool "Flat Memory"
  17         depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE
  18         help
  19           This option allows you to change some of the ways that
  20           Linux manages its memory internally.  Most users will
  21           only have one option here: FLATMEM.  This is normal
  22           and a correct option.
  23
  24           Some users of more advanced features like NUMA and
  25           memory hotplug may have different options here.
  26           DISCONTIGMEM is a more mature, better tested system,
  27           but is incompatible with memory hotplug and may suffer
  28           decreased performance over SPARSEMEM.  If unsure between
  29           "Sparse Memory" and "Discontiguous Memory", choose
  30           "Discontiguous Memory".
  31
  32           If unsure, choose this option (Flat Memory) over any other.
  33
  34 config DISCONTIGMEM_MANUAL
  35         bool "Discontiguous Memory"
  36         depends on ARCH_DISCONTIGMEM_ENABLE
  37         help
  38           This option provides enhanced support for discontiguous
  39           memory systems, over FLATMEM.  These systems have holes
  40           in their physical address spaces, and this option provides
  41           more efficient handling of these holes.  However, the vast
  42           majority of hardware has quite flat address spaces, and
  43           can have degraded performance from the extra overhead that
  44           this option imposes.
  45
  46           Many NUMA configurations will have this as the only option.
  47
  48           If unsure, choose "Flat Memory" over this option.
  49
  50 config SPARSEMEM_MANUAL
  51         bool "Sparse Memory"
  52         depends on ARCH_SPARSEMEM_ENABLE
  53         help
  54           This will be the only option for some systems, including
  55           memory hotplug systems.  This is normal.
  56
  57           For many other systems, this will be an alternative to
  58           "Discontiguous Memory".  This option provides some potential
  59           performance benefits, along with decreased code complexity,
  60           but it is newer, and more experimental.
  61
  62           If unsure, choose "Discontiguous Memory" or "Flat Memory"
  63           over this option.
  64
  65 endchoice
  66
  67 config DISCONTIGMEM
  68         def_bool y
  69         depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL
  70
  71 config SPARSEMEM
  72         def_bool y
  73         depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL
  74
  75 config FLATMEM
  76         def_bool y
  77         depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL
  78
  79 config FLAT_NODE_MEM_MAP
  80         def_bool y
  81         depends on !SPARSEMEM
  82
  83 #
  84 # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's
  85 # to represent different areas of memory.  This variable allows
  86 # those dependencies to exist individually.
  87 #
  88 config NEED_MULTIPLE_NODES
  89         def_bool y
  90         depends on DISCONTIGMEM || NUMA
  91
  92 config HAVE_MEMORY_PRESENT
  93         def_bool y
  94         depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM
  95
  96 #
  97 # SPARSEMEM_EXTREME (which is the default) does some bootmem
  98 # allocations when memory_present() is called.  If this cannot
  99 # be done on your architecture, select this option.  However,
 100 # statically allocating the mem_section[] array can potentially
 101 # consume vast quantities of .bss, so be careful.
 102 #
 103 # This option will also potentially produce smaller runtime code
 104 # with gcc 3.4 and later.
 105 #
 106 config SPARSEMEM_STATIC
 107         bool
 108
 109 #
 110 # Architecture platforms which require a two level mem_section in SPARSEMEM
 111 # must select this option. This is usually for architecture platforms with
 112 # an extremely sparse physical address space.
 113 #
 114 config SPARSEMEM_EXTREME
 115         def_bool y
 116         depends on SPARSEMEM && !SPARSEMEM_STATIC
 117
 118 config SPARSEMEM_VMEMMAP_ENABLE
 119         bool
 120
 121 config SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
 122         def_bool y
 123         depends on SPARSEMEM && X86_64
 124
 125 config SPARSEMEM_VMEMMAP
 126         bool "Sparse Memory virtual memmap"
 127         depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE
 128         default y
 129         help
 130          SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise
 131          pfn_to_page and page_to_pfn operations.  This is the most
 132          efficient option when sufficient kernel resources are available.
 133
 134 config HAVE_MEMBLOCK
 135         bool
 136
 137 config HAVE_MEMBLOCK_NODE_MAP
 138         bool
 139
 140 config HAVE_MEMBLOCK_PHYS_MAP
 141         bool
 142
 143 config HAVE_GENERIC_GUP
 144         bool
 145
 146 config ARCH_DISCARD_MEMBLOCK
 147         bool
 148
 149 config NO_BOOTMEM
 150         bool
 151
 152 config MEMORY_ISOLATION
 153         bool
 154
 155 #
 156 # Only be set on architectures that have completely implemented memory hotplug
 157 # feature. If you are not sure, don't touch it.
 158 #
 159 config HAVE_BOOTMEM_INFO_NODE
 160         def_bool n
 161
 162 # eventually, we can have this option just 'select SPARSEMEM'
 163 config MEMORY_HOTPLUG
 164         bool "Allow for memory hot-add"
 165         depends on SPARSEMEM || X86_64_ACPI_NUMA
 166         depends on ARCH_ENABLE_MEMORY_HOTPLUG
 167
 168 config MEMORY_HOTPLUG_SPARSE
 169         def_bool y
 170         depends on SPARSEMEM && MEMORY_HOTPLUG
 171
 172 config MEMORY_HOTPLUG_DEFAULT_ONLINE
 173         bool "Online the newly added memory blocks by default"
 174         default n
 175         depends on MEMORY_HOTPLUG
 176         help
 177           This option sets the default policy setting for memory hotplug
 178           onlining policy (/sys/devices/system/memory/auto_online_blocks) which
 179           determines what happens to newly added memory regions. Policy setting
 180           can always be changed at runtime.
 181           See Documentation/memory-hotplug.txt for more information.
 182
 183           Say Y here if you want all hot-plugged memory blocks to appear in
 184           'online' state by default.
 185           Say N here if you want the default policy to keep all hot-plugged
 186           memory blocks in 'offline' state.
 187
 188 config MEMORY_HOTREMOVE
 189         bool "Allow for memory hot remove"
 190         select MEMORY_ISOLATION
 191         select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
 192         depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
 193         depends on MIGRATION
 194
 195 # Heavily threaded applications may benefit from splitting the mm-wide
 196 # page_table_lock, so that faults on different parts of the user address
 197 # space can be handled with less contention: split it at this NR_CPUS.
 198 # Default to 4 for wider testing, though 8 might be more appropriate.
 199 # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
 200 # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
 201 # DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page.
 202 #
 203 config SPLIT_PTLOCK_CPUS
 204         int
 205         default "999999" if !MMU
 206         default "999999" if ARM && !CPU_CACHE_VIPT
 207         default "999999" if PARISC && !PA20
 208         default "4"
 209
 210 config ARCH_ENABLE_SPLIT_PMD_PTLOCK
 211         bool
 212
 213 #
 214 # support for memory balloon
 215 config MEMORY_BALLOON
 216         bool
 217
 218 #
 219 # support for memory balloon compaction
 220 config BALLOON_COMPACTION
 221         bool "Allow for balloon memory compaction/migration"
 222         def_bool y
 223         depends on COMPACTION && MEMORY_BALLOON
 224         help
 225           Memory fragmentation introduced by ballooning might reduce
 226           significantly the number of 2MB contiguous memory blocks that can be
 227           used within a guest, thus imposing performance penalties associated
 228           with the reduced number of transparent huge pages that could be used
 229           by the guest workload. Allowing the compaction & migration for memory
 230           pages enlisted as being part of memory balloon devices avoids the
 231           scenario aforementioned and helps improving memory defragmentation.
 232
 233 #
 234 # support for memory compaction
 235 config COMPACTION
 236         bool "Allow for memory compaction"
 237         def_bool y
 238         select MIGRATION
 239         depends on MMU
 240         help
 241           Compaction is the only memory management component to form
 242           high order (larger physically contiguous) memory blocks
 243           reliably. The page allocator relies on compaction heavily and
 244           the lack of the feature can lead to unexpected OOM killer
 245           invocations for high order memory requests. You shouldn't
 246           disable this option unless there really is a strong reason for
 247           it and then we would be really interested to hear about that at
 248           linux-mm@kvack.org.
 249
 250 #
 251 # support for page migration
 252 #
 253 config 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
 265 config ARCH_ENABLE_HUGEPAGE_MIGRATION
 266         bool
 267
 268 config ARCH_ENABLE_THP_MIGRATION
 269         bool
 270
 271 config PHYS_ADDR_T_64BIT
 272         def_bool 64BIT
 273
 274 config BOUNCE
 275         bool "Enable bounce buffers"
 276         default y
 277         depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
 278         help
 279           Enable bounce buffers for devices that cannot access
 280           the full range of memory available to the CPU. Enabled
 281           by default when ZONE_DMA or HIGHMEM is selected, but you
 282           may say n to override this.
 283
 284 config NR_QUICK
 285         int
 286         depends on QUICKLIST
 287         default "1"
 288
 289 config VIRT_TO_BUS
 290         bool
 291         help
 292           An architecture should select this if it implements the
 293           deprecated interface virt_to_bus().  All new architectures
 294           should probably not select this.
 295
 296
 297 config MMU_NOTIFIER
 298         bool
 299         select SRCU
 300
 301 config KSM
 302         bool "Enable KSM for page merging"
 303         depends on MMU
 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
 315 config 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
 334 config ARCH_SUPPORTS_MEMORY_FAILURE
 335         bool
 336
 337 config 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
 349 config HWPOISON_INJECT
 350         tristate "HWPoison pages injector"
 351         depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
 352         select PROC_PAGE_MONITOR
 353
 354 config 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
 382 config TRANSPARENT_HUGEPAGE
 383         bool "Transparent Hugepage Support"
 384         depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE
 385         select COMPACTION
 386         select RADIX_TREE_MULTIORDER
 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
 397 choice
 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.
 419 endchoice
 420
 421 config ARCH_WANTS_THP_SWAP
 422        def_bool n
 423
 424 config THP_SWAP
 425         def_bool y
 426         depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP
 427         help
 428           Swap transparent huge pages in one piece, without splitting.
 429           XXX: For now this only does clustered swap space allocation.
 430
 431           For selection by architectures with reasonable THP sizes.
 432
 433 config  TRANSPARENT_HUGE_PAGECACHE
 434         def_bool y
 435         depends on TRANSPARENT_HUGEPAGE
 436
 437 #
 438 # UP and nommu archs use km based percpu allocator
 439 #
 440 config NEED_PER_CPU_KM
 441         depends on !SMP
 442         bool
 443         default y
 444
 445 config CLEANCACHE
 446         bool "Enable cleancache driver to cache clean pages if tmem is present"
 447         default n
 448         help
 449           Cleancache can be thought of as a page-granularity victim cache
 450           for clean pages that the kernel's pageframe replacement algorithm
 451           (PFRA) would like to keep around, but can't since there isn't enough
 452           memory.  So when the PFRA "evicts" a page, it first attempts to use
 453           cleancache code to put the data contained in that page into
 454           "transcendent memory", memory that is not directly accessible or
 455           addressable by the kernel and is of unknown and possibly
 456           time-varying size.  And when a cleancache-enabled
 457           filesystem wishes to access a page in a file on disk, it first
 458           checks cleancache to see if it already contains it; if it does,
 459           the page is copied into the kernel and a disk access is avoided.
 460           When a transcendent memory driver is available (such as zcache or
 461           Xen transcendent memory), a significant I/O reduction
 462           may be achieved.  When none is available, all cleancache calls
 463           are reduced to a single pointer-compare-against-NULL resulting
 464           in a negligible performance hit.
 465
 466           If unsure, say Y to enable cleancache
 467
 468 config FRONTSWAP
 469         bool "Enable frontswap to cache swap pages if tmem is present"
 470         depends on SWAP
 471         default n
 472         help
 473           Frontswap is so named because it can be thought of as the opposite
 474           of a "backing" store for a swap device.  The data is stored into
 475           "transcendent memory", memory that is not directly accessible or
 476           addressable by the kernel and is of unknown and possibly
 477           time-varying size.  When space in transcendent memory is available,
 478           a significant swap I/O reduction may be achieved.  When none is
 479           available, all frontswap calls are reduced to a single pointer-
 480           compare-against-NULL resulting in a negligible performance hit
 481           and swap data is stored as normal on the matching swap device.
 482
 483           If unsure, say Y to enable frontswap.
 484
 485 config CMA
 486         bool "Contiguous Memory Allocator"
 487         depends on HAVE_MEMBLOCK && MMU
 488         select MIGRATION
 489         select MEMORY_ISOLATION
 490         help
 491           This enables the Contiguous Memory Allocator which allows other
 492           subsystems to allocate big physically-contiguous blocks of memory.
 493           CMA reserves a region of memory and allows only movable pages to
 494           be allocated from it. This way, the kernel can use the memory for
 495           pagecache and when a subsystem requests for contiguous area, the
 496           allocated pages are migrated away to serve the contiguous request.
 497
 498           If unsure, say "n".
 499
 500 config CMA_DEBUG
 501         bool "CMA debug messages (DEVELOPMENT)"
 502         depends on DEBUG_KERNEL && CMA
 503         help
 504           Turns on debug messages in CMA.  This produces KERN_DEBUG
 505           messages for every CMA call as well as various messages while
 506           processing calls such as dma_alloc_from_contiguous().
 507           This option does not affect warning and error messages.
 508
 509 config CMA_DEBUGFS
 510         bool "CMA debugfs interface"
 511         depends on CMA && DEBUG_FS
 512         help
 513           Turns on the DebugFS interface for CMA.
 514
 515 config CMA_AREAS
 516         int "Maximum count of the CMA areas"
 517         depends on CMA
 518         default 7
 519         help
 520           CMA allows to create CMA areas for particular purpose, mainly,
 521           used as device private area. This parameter sets the maximum
 522           number of CMA area in the system.
 523
 524           If unsure, leave the default value "7".
 525
 526 config MEM_SOFT_DIRTY
 527         bool "Track memory changes"
 528         depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS
 529         select PROC_PAGE_MONITOR
 530         help
 531           This option enables memory changes tracking by introducing a
 532           soft-dirty bit on pte-s. This bit it set when someone writes
 533           into a page just as regular dirty bit, but unlike the latter
 534           it can be cleared by hands.
 535
 536           See Documentation/admin-guide/mm/soft-dirty.rst for more details.
 537
 538 config ZSWAP
 539         bool "Compressed cache for swap pages (EXPERIMENTAL)"
 540         depends on FRONTSWAP && CRYPTO=y
 541         select CRYPTO_LZO
 542         select ZPOOL
 543         default n
 544         help
 545           A lightweight compressed cache for swap pages.  It takes
 546           pages that are in the process of being swapped out and attempts to
 547           compress them into a dynamically allocated RAM-based memory pool.
 548           This can result in a significant I/O reduction on swap device and,
 549           in the case where decompressing from RAM is faster that swap device
 550           reads, can also improve workload performance.
 551
 552           This is marked experimental because it is a new feature (as of
 553           v3.11) that interacts heavily with memory reclaim.  While these
 554           interactions don't cause any known issues on simple memory setups,
 555           they have not be fully explored on the large set of potential
 556           configurations and workloads that exist.
 557
 558 config ZPOOL
 559         tristate "Common API for compressed memory storage"
 560         default n
 561         help
 562           Compressed memory storage API.  This allows using either zbud or
 563           zsmalloc.
 564
 565 config ZBUD
 566         tristate "Low (Up to 2x) density storage for compressed pages"
 567         default n
 568         help
 569           A special purpose allocator for storing compressed pages.
 570           It is designed to store up to two compressed pages per physical
 571           page.  While this design limits storage density, it has simple and
 572           deterministic reclaim properties that make it preferable to a higher
 573           density approach when reclaim will be used.
 574
 575 config Z3FOLD
 576         tristate "Up to 3x density storage for compressed pages"
 577         depends on ZPOOL
 578         default n
 579         help
 580           A special purpose allocator for storing compressed pages.
 581           It is designed to store up to three compressed pages per physical
 582           page. It is a ZBUD derivative so the simplicity and determinism are
 583           still there.
 584
 585 config ZSMALLOC
 586         tristate "Memory allocator for compressed pages"
 587         depends on MMU
 588         default n
 589         help
 590           zsmalloc is a slab-based memory allocator designed to store
 591           compressed RAM pages.  zsmalloc uses virtual memory mapping
 592           in order to reduce fragmentation.  However, this results in a
 593           non-standard allocator interface where a handle, not a pointer, is
 594           returned by an alloc().  This handle must be mapped in order to
 595           access the allocated space.
 596
 597 config PGTABLE_MAPPING
 598         bool "Use page table mapping to access object in zsmalloc"
 599         depends on ZSMALLOC
 600         help
 601           By default, zsmalloc uses a copy-based object mapping method to
 602           access allocations that span two pages. However, if a particular
 603           architecture (ex, ARM) performs VM mapping faster than copying,
 604           then you should select this. This causes zsmalloc to use page table
 605           mapping rather than copying for object mapping.
 606
 607           You can check speed with zsmalloc benchmark:
 608           https://github.com/spartacus06/zsmapbench
 609
 610 config ZSMALLOC_STAT
 611         bool "Export zsmalloc statistics"
 612         depends on ZSMALLOC
 613         select DEBUG_FS
 614         help
 615           This option enables code in the zsmalloc to collect various
 616           statistics about whats happening in zsmalloc and exports that
 617           information to userspace via debugfs.
 618           If unsure, say N.
 619
 620 config GENERIC_EARLY_IOREMAP
 621         bool
 622
 623 config MAX_STACK_SIZE_MB
 624         int "Maximum user stack size for 32-bit processes (MB)"
 625         default 80
 626         range 8 2048
 627         depends on STACK_GROWSUP && (!64BIT || COMPAT)
 628         help
 629           This is the maximum stack size in Megabytes in the VM layout of 32-bit
 630           user processes when the stack grows upwards (currently only on parisc
 631           arch). The stack will be located at the highest memory address minus
 632           the given value, unless the RLIMIT_STACK hard limit is changed to a
 633           smaller value in which case that is used.
 634
 635           A sane initial value is 80 MB.
 636
 637 config DEFERRED_STRUCT_PAGE_INIT
 638         bool "Defer initialisation of struct pages to kthreads"
 639         default n
 640         depends on NO_BOOTMEM
 641         depends on !FLATMEM
 642         depends on !NEED_PER_CPU_KM
 643         help
 644           Ordinarily all struct pages are initialised during early boot in a
 645           single thread. On very large machines this can take a considerable
 646           amount of time. If this option is set, large machines will bring up
 647           a subset of memmap at boot and then initialise the rest in parallel
 648           by starting one-off "pgdatinitX" kernel thread for each node X. This
 649           has a potential performance impact on processes running early in the
 650           lifetime of the system until these kthreads finish the
 651           initialisation.
 652
 653 config IDLE_PAGE_TRACKING
 654         bool "Enable idle page tracking"
 655         depends on SYSFS && MMU
 656         select PAGE_EXTENSION if !64BIT
 657         help
 658           This feature allows to estimate the amount of user pages that have
 659           not been touched during a given period of time. This information can
 660           be useful to tune memory cgroup limits and/or for job placement
 661           within a compute cluster.
 662
 663           See Documentation/admin-guide/mm/idle_page_tracking.rst for
 664           more details.
 665
 666 # arch_add_memory() comprehends device memory
 667 config ARCH_HAS_ZONE_DEVICE
 668         bool
 669
 670 config ZONE_DEVICE
 671         bool "Device memory (pmem, HMM, etc...) hotplug support"
 672         depends on MEMORY_HOTPLUG
 673         depends on MEMORY_HOTREMOVE
 674         depends on SPARSEMEM_VMEMMAP
 675         depends on ARCH_HAS_ZONE_DEVICE
 676         select RADIX_TREE_MULTIORDER
 677
 678         help
 679           Device memory hotplug support allows for establishing pmem,
 680           or other device driver discovered memory regions, in the
 681           memmap. This allows pfn_to_page() lookups of otherwise
 682           "device-physical" addresses which is needed for using a DAX
 683           mapping in an O_DIRECT operation, among other things.
 684
 685           If FS_DAX is enabled, then say Y.
 686
 687 config ARCH_HAS_HMM
 688         bool
 689         default y
 690         depends on (X86_64 || PPC64)
 691         depends on ZONE_DEVICE
 692         depends on MMU && 64BIT
 693         depends on MEMORY_HOTPLUG
 694         depends on MEMORY_HOTREMOVE
 695         depends on SPARSEMEM_VMEMMAP
 696
 697 config MIGRATE_VMA_HELPER
 698         bool
 699
 700 config DEV_PAGEMAP_OPS
 701         bool
 702
 703 config HMM
 704         bool
 705         select MIGRATE_VMA_HELPER
 706
 707 config HMM_MIRROR
 708         bool "HMM mirror CPU page table into a device page table"
 709         depends on ARCH_HAS_HMM
 710         select MMU_NOTIFIER
 711         select HMM
 712         help
 713           Select HMM_MIRROR if you want to mirror range of the CPU page table of a
 714           process into a device page table. Here, mirror means "keep synchronized".
 715           Prerequisites: the device must provide the ability to write-protect its
 716           page tables (at PAGE_SIZE granularity), and must be able to recover from
 717           the resulting potential page faults.
 718
 719 config DEVICE_PRIVATE
 720         bool "Unaddressable device memory (GPU memory, ...)"
 721         depends on ARCH_HAS_HMM
 722         select HMM
 723         select DEV_PAGEMAP_OPS
 724
 725         help
 726           Allows creation of struct pages to represent unaddressable device
 727           memory; i.e., memory that is only accessible from the device (or
 728           group of devices). You likely also want to select HMM_MIRROR.
 729
 730 config DEVICE_PUBLIC
 731         bool "Addressable device memory (like GPU memory)"
 732         depends on ARCH_HAS_HMM
 733         select HMM
 734         select DEV_PAGEMAP_OPS
 735
 736         help
 737           Allows creation of struct pages to represent addressable device
 738           memory; i.e., memory that is accessible from both the device and
 739           the CPU
 740
 741 config FRAME_VECTOR
 742         bool
 743
 744 config ARCH_USES_HIGH_VMA_FLAGS
 745         bool
 746 config ARCH_HAS_PKEYS
 747         bool
 748
 749 config PERCPU_STATS
 750         bool "Collect percpu memory statistics"
 751         default n
 752         help
 753           This feature collects and exposes statistics via debugfs. The
 754           information includes global and per chunk statistics, which can
 755           be used to help understand percpu memory usage.
 756
 757 config GUP_BENCHMARK
 758         bool "Enable infrastructure for get_user_pages_fast() benchmarking"
 759         default n
 760         help
 761           Provides /sys/kernel/debug/gup_benchmark that helps with testing
 762           performance of get_user_pages_fast().
 763
 764           See tools/testing/selftests/vm/gup_benchmark.c
 765
 766 config ARCH_HAS_PTE_SPECIAL
 767         bool
 768
 769 endmenu