1config SELECT_MEMORY_MODEL 2 def_bool y 3 depends on ARCH_SELECT_MEMORY_MODEL 4 5choice 6 prompt "Memory model" 7 depends on SELECT_MEMORY_MODEL 8 default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT 9 default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT 10 default FLATMEM_MANUAL 11 12config FLATMEM_MANUAL 13 bool "Flat Memory" 14 depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE 15 help 16 This option allows you to change some of the ways that 17 Linux manages its memory internally. Most users will 18 only have one option here: FLATMEM. This is normal 19 and a correct option. 20 21 Some users of more advanced features like NUMA and 22 memory hotplug may have different options here. 23 DISCONTIGMEM is a more mature, better tested system, 24 but is incompatible with memory hotplug and may suffer 25 decreased performance over SPARSEMEM. If unsure between 26 "Sparse Memory" and "Discontiguous Memory", choose 27 "Discontiguous Memory". 28 29 If unsure, choose this option (Flat Memory) over any other. 30 31config DISCONTIGMEM_MANUAL 32 bool "Discontiguous Memory" 33 depends on ARCH_DISCONTIGMEM_ENABLE 34 help 35 This option provides enhanced support for discontiguous 36 memory systems, over FLATMEM. These systems have holes 37 in their physical address spaces, and this option provides 38 more efficient handling of these holes. However, the vast 39 majority of hardware has quite flat address spaces, and 40 can have degraded performance from the extra overhead that 41 this option imposes. 42 43 Many NUMA configurations will have this as the only option. 44 45 If unsure, choose "Flat Memory" over this option. 46 47config SPARSEMEM_MANUAL 48 bool "Sparse Memory" 49 depends on ARCH_SPARSEMEM_ENABLE 50 help 51 This will be the only option for some systems, including 52 memory hotplug systems. This is normal. 53 54 For many other systems, this will be an alternative to 55 "Discontiguous Memory". This option provides some potential 56 performance benefits, along with decreased code complexity, 57 but it is newer, and more experimental. 58 59 If unsure, choose "Discontiguous Memory" or "Flat Memory" 60 over this option. 61 62endchoice 63 64config DISCONTIGMEM 65 def_bool y 66 depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL 67 68config SPARSEMEM 69 def_bool y 70 depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL 71 72config FLATMEM 73 def_bool y 74 depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL 75 76config FLAT_NODE_MEM_MAP 77 def_bool y 78 depends on !SPARSEMEM 79 80# 81# Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's 82# to represent different areas of memory. This variable allows 83# those dependencies to exist individually. 84# 85config NEED_MULTIPLE_NODES 86 def_bool y 87 depends on DISCONTIGMEM || NUMA 88 89config HAVE_MEMORY_PRESENT 90 def_bool y 91 depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM 92 93# 94# SPARSEMEM_EXTREME (which is the default) does some bootmem 95# allocations when memory_present() is called. If this cannot 96# be done on your architecture, select this option. However, 97# statically allocating the mem_section[] array can potentially 98# consume vast quantities of .bss, so be careful. 99# 100# This option will also potentially produce smaller runtime code 101# with gcc 3.4 and later. 102# 103config SPARSEMEM_STATIC 104 bool 105 106# 107# Architecture platforms which require a two level mem_section in SPARSEMEM 108# must select this option. This is usually for architecture platforms with 109# an extremely sparse physical address space. 110# 111config SPARSEMEM_EXTREME 112 def_bool y 113 depends on SPARSEMEM && !SPARSEMEM_STATIC 114 115config SPARSEMEM_VMEMMAP_ENABLE 116 bool 117 118config SPARSEMEM_ALLOC_MEM_MAP_TOGETHER 119 def_bool y 120 depends on SPARSEMEM && X86_64 121 122config SPARSEMEM_VMEMMAP 123 bool "Sparse Memory virtual memmap" 124 depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE 125 default y 126 help 127 SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise 128 pfn_to_page and page_to_pfn operations. This is the most 129 efficient option when sufficient kernel resources are available. 130 131config HAVE_MEMBLOCK 132 bool 133 134config HAVE_MEMBLOCK_NODE_MAP 135 bool 136 137config HAVE_MEMBLOCK_PHYS_MAP 138 bool 139 140config HAVE_GENERIC_GUP 141 bool 142 143config ARCH_DISCARD_MEMBLOCK 144 bool 145 146config NO_BOOTMEM 147 bool 148 149config MEMORY_ISOLATION 150 bool 151 152# 153# Only be set on architectures that have completely implemented memory hotplug 154# feature. If you are not sure, don't touch it. 155# 156config HAVE_BOOTMEM_INFO_NODE 157 def_bool n 158 159# eventually, we can have this option just 'select SPARSEMEM' 160config MEMORY_HOTPLUG 161 bool "Allow for memory hot-add" 162 depends on SPARSEMEM || X86_64_ACPI_NUMA 163 depends on ARCH_ENABLE_MEMORY_HOTPLUG 164 165config MEMORY_HOTPLUG_SPARSE 166 def_bool y 167 depends on SPARSEMEM && MEMORY_HOTPLUG 168 169config MEMORY_HOTPLUG_DEFAULT_ONLINE 170 bool "Online the newly added memory blocks by default" 171 default n 172 depends on MEMORY_HOTPLUG 173 help 174 This option sets the default policy setting for memory hotplug 175 onlining policy (/sys/devices/system/memory/auto_online_blocks) which 176 determines what happens to newly added memory regions. Policy setting 177 can always be changed at runtime. 178 See Documentation/memory-hotplug.txt for more information. 179 180 Say Y here if you want all hot-plugged memory blocks to appear in 181 'online' state by default. 182 Say N here if you want the default policy to keep all hot-plugged 183 memory blocks in 'offline' state. 184 185config MEMORY_HOTREMOVE 186 bool "Allow for memory hot remove" 187 select MEMORY_ISOLATION 188 select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64) 189 depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE 190 depends on MIGRATION 191 192# Heavily threaded applications may benefit from splitting the mm-wide 193# page_table_lock, so that faults on different parts of the user address 194# space can be handled with less contention: split it at this NR_CPUS. 195# Default to 4 for wider testing, though 8 might be more appropriate. 196# ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. 197# PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. 198# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. 199# 200config SPLIT_PTLOCK_CPUS 201 int 202 default "999999" if !MMU 203 default "999999" if ARM && !CPU_CACHE_VIPT 204 default "999999" if PARISC && !PA20 205 default "4" 206 207config ARCH_ENABLE_SPLIT_PMD_PTLOCK 208 bool 209 210# 211# support for memory balloon 212config MEMORY_BALLOON 213 bool 214 215# 216# support for memory balloon compaction 217config BALLOON_COMPACTION 218 bool "Allow for balloon memory compaction/migration" 219 def_bool y 220 depends on COMPACTION && MEMORY_BALLOON 221 help 222 Memory fragmentation introduced by ballooning might reduce 223 significantly the number of 2MB contiguous memory blocks that can be 224 used within a guest, thus imposing performance penalties associated 225 with the reduced number of transparent huge pages that could be used 226 by the guest workload. Allowing the compaction & migration for memory 227 pages enlisted as being part of memory balloon devices avoids the 228 scenario aforementioned and helps improving memory defragmentation. 229 230# 231# support for memory compaction 232config COMPACTION 233 bool "Allow for memory compaction" 234 def_bool y 235 select MIGRATION 236 depends on MMU 237 help 238 Compaction is the only memory management component to form 239 high order (larger physically contiguous) memory blocks 240 reliably. The page allocator relies on compaction heavily and 241 the lack of the feature can lead to unexpected OOM killer 242 invocations for high order memory requests. You shouldn't 243 disable this option unless there really is a strong reason for 244 it and then we would be really interested to hear about that at 245 linux-mm@kvack.org. 246 247# 248# support for page migration 249# 250config MIGRATION 251 bool "Page migration" 252 def_bool y 253 depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU 254 help 255 Allows the migration of the physical location of pages of processes 256 while the virtual addresses are not changed. This is useful in 257 two situations. The first is on NUMA systems to put pages nearer 258 to the processors accessing. The second is when allocating huge 259 pages as migration can relocate pages to satisfy a huge page 260 allocation instead of reclaiming. 261 262config ARCH_ENABLE_HUGEPAGE_MIGRATION 263 bool 264 265config ARCH_ENABLE_THP_MIGRATION 266 bool 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 && (ZONE_DMA || HIGHMEM) 275 help 276 Enable bounce buffers for devices that cannot access 277 the full range of memory available to the CPU. Enabled 278 by default when ZONE_DMA or HIGHMEM is selected, but you 279 may say n to override this. 280 281config NR_QUICK 282 int 283 depends on QUICKLIST 284 default "1" 285 286config VIRT_TO_BUS 287 bool 288 help 289 An architecture should select this if it implements the 290 deprecated interface virt_to_bus(). All new architectures 291 should probably not select this. 292 293 294config MMU_NOTIFIER 295 bool 296 select SRCU 297 298config KSM 299 bool "Enable KSM for page merging" 300 depends on MMU 301 help 302 Enable Kernel Samepage Merging: KSM periodically scans those areas 303 of an application's address space that an app has advised may be 304 mergeable. When it finds pages of identical content, it replaces 305 the many instances by a single page with that content, so 306 saving memory until one or another app needs to modify the content. 307 Recommended for use with KVM, or with other duplicative applications. 308 See Documentation/vm/ksm.rst for more information: KSM is inactive 309 until a program has madvised that an area is MADV_MERGEABLE, and 310 root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set). 311 312config DEFAULT_MMAP_MIN_ADDR 313 int "Low address space to protect from user allocation" 314 depends on MMU 315 default 4096 316 help 317 This is the portion of low virtual memory which should be protected 318 from userspace allocation. Keeping a user from writing to low pages 319 can help reduce the impact of kernel NULL pointer bugs. 320 321 For most ia64, ppc64 and x86 users with lots of address space 322 a value of 65536 is reasonable and should cause no problems. 323 On arm and other archs it should not be higher than 32768. 324 Programs which use vm86 functionality or have some need to map 325 this low address space will need CAP_SYS_RAWIO or disable this 326 protection by setting the value to 0. 327 328 This value can be changed after boot using the 329 /proc/sys/vm/mmap_min_addr tunable. 330 331config ARCH_SUPPORTS_MEMORY_FAILURE 332 bool 333 334config MEMORY_FAILURE 335 depends on MMU 336 depends on ARCH_SUPPORTS_MEMORY_FAILURE 337 bool "Enable recovery from hardware memory errors" 338 select MEMORY_ISOLATION 339 select RAS 340 help 341 Enables code to recover from some memory failures on systems 342 with MCA recovery. This allows a system to continue running 343 even when some of its memory has uncorrected errors. This requires 344 special hardware support and typically ECC memory. 345 346config HWPOISON_INJECT 347 tristate "HWPoison pages injector" 348 depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS 349 select PROC_PAGE_MONITOR 350 351config NOMMU_INITIAL_TRIM_EXCESS 352 int "Turn on mmap() excess space trimming before booting" 353 depends on !MMU 354 default 1 355 help 356 The NOMMU mmap() frequently needs to allocate large contiguous chunks 357 of memory on which to store mappings, but it can only ask the system 358 allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently 359 more than it requires. To deal with this, mmap() is able to trim off 360 the excess and return it to the allocator. 361 362 If trimming is enabled, the excess is trimmed off and returned to the 363 system allocator, which can cause extra fragmentation, particularly 364 if there are a lot of transient processes. 365 366 If trimming is disabled, the excess is kept, but not used, which for 367 long-term mappings means that the space is wasted. 368 369 Trimming can be dynamically controlled through a sysctl option 370 (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of 371 excess pages there must be before trimming should occur, or zero if 372 no trimming is to occur. 373 374 This option specifies the initial value of this option. The default 375 of 1 says that all excess pages should be trimmed. 376 377 See Documentation/nommu-mmap.txt for more information. 378 379config TRANSPARENT_HUGEPAGE 380 bool "Transparent Hugepage Support" 381 depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE 382 select COMPACTION 383 select RADIX_TREE_MULTIORDER 384 help 385 Transparent Hugepages allows the kernel to use huge pages and 386 huge tlb transparently to the applications whenever possible. 387 This feature can improve computing performance to certain 388 applications by speeding up page faults during memory 389 allocation, by reducing the number of tlb misses and by speeding 390 up the pagetable walking. 391 392 If memory constrained on embedded, you may want to say N. 393 394choice 395 prompt "Transparent Hugepage Support sysfs defaults" 396 depends on TRANSPARENT_HUGEPAGE 397 default TRANSPARENT_HUGEPAGE_ALWAYS 398 help 399 Selects the sysfs defaults for Transparent Hugepage Support. 400 401 config TRANSPARENT_HUGEPAGE_ALWAYS 402 bool "always" 403 help 404 Enabling Transparent Hugepage always, can increase the 405 memory footprint of applications without a guaranteed 406 benefit but it will work automatically for all applications. 407 408 config TRANSPARENT_HUGEPAGE_MADVISE 409 bool "madvise" 410 help 411 Enabling Transparent Hugepage madvise, will only provide a 412 performance improvement benefit to the applications using 413 madvise(MADV_HUGEPAGE) but it won't risk to increase the 414 memory footprint of applications without a guaranteed 415 benefit. 416endchoice 417 418config ARCH_WANTS_THP_SWAP 419 def_bool n 420 421config THP_SWAP 422 def_bool y 423 depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP 424 help 425 Swap transparent huge pages in one piece, without splitting. 426 XXX: For now this only does clustered swap space allocation. 427 428 For selection by architectures with reasonable THP sizes. 429 430config 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# 437config NEED_PER_CPU_KM 438 depends on !SMP 439 bool 440 default y 441 442config 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 465config 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 482config 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 497config 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 506config CMA_DEBUGFS 507 bool "CMA debugfs interface" 508 depends on CMA && DEBUG_FS 509 help 510 Turns on the DebugFS interface for CMA. 511 512config 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 523config 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 535config 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 555config 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 562config 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 572config 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 582config 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 594config 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 607config 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 617config GENERIC_EARLY_IOREMAP 618 bool 619 620config 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 634config DEFERRED_STRUCT_PAGE_INIT 635 bool "Defer initialisation of struct pages to kthreads" 636 default n 637 depends on NO_BOOTMEM 638 depends on !FLATMEM 639 depends on !NEED_PER_CPU_KM 640 help 641 Ordinarily all struct pages are initialised during early boot in a 642 single thread. On very large machines this can take a considerable 643 amount of time. If this option is set, large machines will bring up 644 a subset of memmap at boot and then initialise the rest in parallel 645 by starting one-off "pgdatinitX" kernel thread for each node X. This 646 has a potential performance impact on processes running early in the 647 lifetime of the system until these kthreads finish the 648 initialisation. 649 650config IDLE_PAGE_TRACKING 651 bool "Enable idle page tracking" 652 depends on SYSFS && MMU 653 select PAGE_EXTENSION if !64BIT 654 help 655 This feature allows to estimate the amount of user pages that have 656 not been touched during a given period of time. This information can 657 be useful to tune memory cgroup limits and/or for job placement 658 within a compute cluster. 659 660 See Documentation/admin-guide/mm/idle_page_tracking.rst for 661 more details. 662 663# arch_add_memory() comprehends device memory 664config ARCH_HAS_ZONE_DEVICE 665 bool 666 667config ZONE_DEVICE 668 bool "Device memory (pmem, HMM, etc...) hotplug support" 669 depends on MEMORY_HOTPLUG 670 depends on MEMORY_HOTREMOVE 671 depends on SPARSEMEM_VMEMMAP 672 depends on ARCH_HAS_ZONE_DEVICE 673 select RADIX_TREE_MULTIORDER 674 675 help 676 Device memory hotplug support allows for establishing pmem, 677 or other device driver discovered memory regions, in the 678 memmap. This allows pfn_to_page() lookups of otherwise 679 "device-physical" addresses which is needed for using a DAX 680 mapping in an O_DIRECT operation, among other things. 681 682 If FS_DAX is enabled, then say Y. 683 684config ARCH_HAS_HMM 685 bool 686 default y 687 depends on (X86_64 || PPC64) 688 depends on ZONE_DEVICE 689 depends on MMU && 64BIT 690 depends on MEMORY_HOTPLUG 691 depends on MEMORY_HOTREMOVE 692 depends on SPARSEMEM_VMEMMAP 693 694config MIGRATE_VMA_HELPER 695 bool 696 697config DEV_PAGEMAP_OPS 698 bool 699 700config HMM 701 bool 702 select MIGRATE_VMA_HELPER 703 704config HMM_MIRROR 705 bool "HMM mirror CPU page table into a device page table" 706 depends on ARCH_HAS_HMM 707 select MMU_NOTIFIER 708 select HMM 709 help 710 Select HMM_MIRROR if you want to mirror range of the CPU page table of a 711 process into a device page table. Here, mirror means "keep synchronized". 712 Prerequisites: the device must provide the ability to write-protect its 713 page tables (at PAGE_SIZE granularity), and must be able to recover from 714 the resulting potential page faults. 715 716config DEVICE_PRIVATE 717 bool "Unaddressable device memory (GPU memory, ...)" 718 depends on ARCH_HAS_HMM 719 select HMM 720 select DEV_PAGEMAP_OPS 721 722 help 723 Allows creation of struct pages to represent unaddressable device 724 memory; i.e., memory that is only accessible from the device (or 725 group of devices). You likely also want to select HMM_MIRROR. 726 727config DEVICE_PUBLIC 728 bool "Addressable device memory (like GPU memory)" 729 depends on ARCH_HAS_HMM 730 select HMM 731 select DEV_PAGEMAP_OPS 732 733 help 734 Allows creation of struct pages to represent addressable device 735 memory; i.e., memory that is accessible from both the device and 736 the CPU 737 738config FRAME_VECTOR 739 bool 740 741config ARCH_USES_HIGH_VMA_FLAGS 742 bool 743config ARCH_HAS_PKEYS 744 bool 745 746config PERCPU_STATS 747 bool "Collect percpu memory statistics" 748 default n 749 help 750 This feature collects and exposes statistics via debugfs. The 751 information includes global and per chunk statistics, which can 752 be used to help understand percpu memory usage. 753 754config GUP_BENCHMARK 755 bool "Enable infrastructure for get_user_pages_fast() benchmarking" 756 default n 757 help 758 Provides /sys/kernel/debug/gup_benchmark that helps with testing 759 performance of get_user_pages_fast(). 760 761 See tools/testing/selftests/vm/gup_benchmark.c 762 763config ARCH_HAS_PTE_SPECIAL 764 bool 765