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