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