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