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