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