xref: /openbmc/linux/mm/Kconfig (revision 9d749629)
1config SELECT_MEMORY_MODEL
2	def_bool y
3	depends on EXPERIMENTAL || 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 an 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	boolean
133
134config HAVE_MEMBLOCK_NODE_MAP
135	boolean
136
137config ARCH_DISCARD_MEMBLOCK
138	boolean
139
140config NO_BOOTMEM
141	boolean
142
143config MEMORY_ISOLATION
144	boolean
145
146config MOVABLE_NODE
147	boolean "Enable to assign a node which has only movable memory"
148	depends on HAVE_MEMBLOCK
149	depends on NO_BOOTMEM
150	depends on X86_64
151	depends on NUMA
152	default n
153	help
154	  Allow a node to have only movable memory.  Pages used by the kernel,
155	  such as direct mapping pages cannot be migrated.  So the corresponding
156	  memory device cannot be hotplugged.  This option allows users to
157	  online all the memory of a node as movable memory so that the whole
158	  node can be hotplugged.  Users who don't use the memory hotplug
159	  feature are fine with this option on since they don't online memory
160	  as movable.
161
162	  Say Y here if you want to hotplug a whole node.
163	  Say N here if you want kernel to use memory on all nodes evenly.
164
165# eventually, we can have this option just 'select SPARSEMEM'
166config MEMORY_HOTPLUG
167	bool "Allow for memory hot-add"
168	select MEMORY_ISOLATION
169	depends on SPARSEMEM || X86_64_ACPI_NUMA
170	depends on HOTPLUG && ARCH_ENABLE_MEMORY_HOTPLUG
171	depends on (IA64 || X86 || PPC_BOOK3S_64 || SUPERH || S390)
172
173config MEMORY_HOTPLUG_SPARSE
174	def_bool y
175	depends on SPARSEMEM && MEMORY_HOTPLUG
176
177config MEMORY_HOTREMOVE
178	bool "Allow for memory hot remove"
179	depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
180	depends on MIGRATION
181
182#
183# If we have space for more page flags then we can enable additional
184# optimizations and functionality.
185#
186# Regular Sparsemem takes page flag bits for the sectionid if it does not
187# use a virtual memmap. Disable extended page flags for 32 bit platforms
188# that require the use of a sectionid in the page flags.
189#
190config PAGEFLAGS_EXTENDED
191	def_bool y
192	depends on 64BIT || SPARSEMEM_VMEMMAP || !SPARSEMEM
193
194# Heavily threaded applications may benefit from splitting the mm-wide
195# page_table_lock, so that faults on different parts of the user address
196# space can be handled with less contention: split it at this NR_CPUS.
197# Default to 4 for wider testing, though 8 might be more appropriate.
198# ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
199# PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
200# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page.
201#
202config SPLIT_PTLOCK_CPUS
203	int
204	default "999999" if ARM && !CPU_CACHE_VIPT
205	default "999999" if PARISC && !PA20
206	default "999999" if DEBUG_SPINLOCK || DEBUG_LOCK_ALLOC
207	default "4"
208
209#
210# support for memory balloon compaction
211config BALLOON_COMPACTION
212	bool "Allow for balloon memory compaction/migration"
213	def_bool y
214	depends on COMPACTION && VIRTIO_BALLOON
215	help
216	  Memory fragmentation introduced by ballooning might reduce
217	  significantly the number of 2MB contiguous memory blocks that can be
218	  used within a guest, thus imposing performance penalties associated
219	  with the reduced number of transparent huge pages that could be used
220	  by the guest workload. Allowing the compaction & migration for memory
221	  pages enlisted as being part of memory balloon devices avoids the
222	  scenario aforementioned and helps improving memory defragmentation.
223
224#
225# support for memory compaction
226config COMPACTION
227	bool "Allow for memory compaction"
228	def_bool y
229	select MIGRATION
230	depends on MMU
231	help
232	  Allows the compaction of memory for the allocation of huge pages.
233
234#
235# support for page migration
236#
237config MIGRATION
238	bool "Page migration"
239	def_bool y
240	depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA
241	help
242	  Allows the migration of the physical location of pages of processes
243	  while the virtual addresses are not changed. This is useful in
244	  two situations. The first is on NUMA systems to put pages nearer
245	  to the processors accessing. The second is when allocating huge
246	  pages as migration can relocate pages to satisfy a huge page
247	  allocation instead of reclaiming.
248
249config PHYS_ADDR_T_64BIT
250	def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
251
252config ZONE_DMA_FLAG
253	int
254	default "0" if !ZONE_DMA
255	default "1"
256
257config BOUNCE
258	def_bool y
259	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
260
261# On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will often
262# have more than 4GB of memory, but we don't currently use the IOTLB to present
263# a 32-bit address to OHCI.  So we need to use a bounce pool instead.
264#
265# We also use the bounce pool to provide stable page writes for jbd.  jbd
266# initiates buffer writeback without locking the page or setting PG_writeback,
267# and fixing that behavior (a second time; jbd2 doesn't have this problem) is
268# a major rework effort.  Instead, use the bounce buffer to snapshot pages
269# (until jbd goes away).  The only jbd user is ext3.
270config NEED_BOUNCE_POOL
271	bool
272	default y if (TILE && USB_OHCI_HCD) || (BLK_DEV_INTEGRITY && JBD)
273
274config NR_QUICK
275	int
276	depends on QUICKLIST
277	default "2" if AVR32
278	default "1"
279
280config VIRT_TO_BUS
281	def_bool y
282	depends on !ARCH_NO_VIRT_TO_BUS
283
284config MMU_NOTIFIER
285	bool
286
287config KSM
288	bool "Enable KSM for page merging"
289	depends on MMU
290	help
291	  Enable Kernel Samepage Merging: KSM periodically scans those areas
292	  of an application's address space that an app has advised may be
293	  mergeable.  When it finds pages of identical content, it replaces
294	  the many instances by a single page with that content, so
295	  saving memory until one or another app needs to modify the content.
296	  Recommended for use with KVM, or with other duplicative applications.
297	  See Documentation/vm/ksm.txt for more information: KSM is inactive
298	  until a program has madvised that an area is MADV_MERGEABLE, and
299	  root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set).
300
301config DEFAULT_MMAP_MIN_ADDR
302        int "Low address space to protect from user allocation"
303	depends on MMU
304        default 4096
305        help
306	  This is the portion of low virtual memory which should be protected
307	  from userspace allocation.  Keeping a user from writing to low pages
308	  can help reduce the impact of kernel NULL pointer bugs.
309
310	  For most ia64, ppc64 and x86 users with lots of address space
311	  a value of 65536 is reasonable and should cause no problems.
312	  On arm and other archs it should not be higher than 32768.
313	  Programs which use vm86 functionality or have some need to map
314	  this low address space will need CAP_SYS_RAWIO or disable this
315	  protection by setting the value to 0.
316
317	  This value can be changed after boot using the
318	  /proc/sys/vm/mmap_min_addr tunable.
319
320config ARCH_SUPPORTS_MEMORY_FAILURE
321	bool
322
323config MEMORY_FAILURE
324	depends on MMU
325	depends on ARCH_SUPPORTS_MEMORY_FAILURE
326	bool "Enable recovery from hardware memory errors"
327	select MEMORY_ISOLATION
328	help
329	  Enables code to recover from some memory failures on systems
330	  with MCA recovery. This allows a system to continue running
331	  even when some of its memory has uncorrected errors. This requires
332	  special hardware support and typically ECC memory.
333
334config HWPOISON_INJECT
335	tristate "HWPoison pages injector"
336	depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
337	select PROC_PAGE_MONITOR
338
339config NOMMU_INITIAL_TRIM_EXCESS
340	int "Turn on mmap() excess space trimming before booting"
341	depends on !MMU
342	default 1
343	help
344	  The NOMMU mmap() frequently needs to allocate large contiguous chunks
345	  of memory on which to store mappings, but it can only ask the system
346	  allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently
347	  more than it requires.  To deal with this, mmap() is able to trim off
348	  the excess and return it to the allocator.
349
350	  If trimming is enabled, the excess is trimmed off and returned to the
351	  system allocator, which can cause extra fragmentation, particularly
352	  if there are a lot of transient processes.
353
354	  If trimming is disabled, the excess is kept, but not used, which for
355	  long-term mappings means that the space is wasted.
356
357	  Trimming can be dynamically controlled through a sysctl option
358	  (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of
359	  excess pages there must be before trimming should occur, or zero if
360	  no trimming is to occur.
361
362	  This option specifies the initial value of this option.  The default
363	  of 1 says that all excess pages should be trimmed.
364
365	  See Documentation/nommu-mmap.txt for more information.
366
367config TRANSPARENT_HUGEPAGE
368	bool "Transparent Hugepage Support"
369	depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE
370	select COMPACTION
371	help
372	  Transparent Hugepages allows the kernel to use huge pages and
373	  huge tlb transparently to the applications whenever possible.
374	  This feature can improve computing performance to certain
375	  applications by speeding up page faults during memory
376	  allocation, by reducing the number of tlb misses and by speeding
377	  up the pagetable walking.
378
379	  If memory constrained on embedded, you may want to say N.
380
381choice
382	prompt "Transparent Hugepage Support sysfs defaults"
383	depends on TRANSPARENT_HUGEPAGE
384	default TRANSPARENT_HUGEPAGE_ALWAYS
385	help
386	  Selects the sysfs defaults for Transparent Hugepage Support.
387
388	config TRANSPARENT_HUGEPAGE_ALWAYS
389		bool "always"
390	help
391	  Enabling Transparent Hugepage always, can increase the
392	  memory footprint of applications without a guaranteed
393	  benefit but it will work automatically for all applications.
394
395	config TRANSPARENT_HUGEPAGE_MADVISE
396		bool "madvise"
397	help
398	  Enabling Transparent Hugepage madvise, will only provide a
399	  performance improvement benefit to the applications using
400	  madvise(MADV_HUGEPAGE) but it won't risk to increase the
401	  memory footprint of applications without a guaranteed
402	  benefit.
403endchoice
404
405config CROSS_MEMORY_ATTACH
406	bool "Cross Memory Support"
407	depends on MMU
408	default y
409	help
410	  Enabling this option adds the system calls process_vm_readv and
411	  process_vm_writev which allow a process with the correct privileges
412	  to directly read from or write to to another process's address space.
413	  See the man page for more details.
414
415#
416# UP and nommu archs use km based percpu allocator
417#
418config NEED_PER_CPU_KM
419	depends on !SMP
420	bool
421	default y
422
423config CLEANCACHE
424	bool "Enable cleancache driver to cache clean pages if tmem is present"
425	default n
426	help
427	  Cleancache can be thought of as a page-granularity victim cache
428	  for clean pages that the kernel's pageframe replacement algorithm
429	  (PFRA) would like to keep around, but can't since there isn't enough
430	  memory.  So when the PFRA "evicts" a page, it first attempts to use
431	  cleancache code to put the data contained in that page into
432	  "transcendent memory", memory that is not directly accessible or
433	  addressable by the kernel and is of unknown and possibly
434	  time-varying size.  And when a cleancache-enabled
435	  filesystem wishes to access a page in a file on disk, it first
436	  checks cleancache to see if it already contains it; if it does,
437	  the page is copied into the kernel and a disk access is avoided.
438	  When a transcendent memory driver is available (such as zcache or
439	  Xen transcendent memory), a significant I/O reduction
440	  may be achieved.  When none is available, all cleancache calls
441	  are reduced to a single pointer-compare-against-NULL resulting
442	  in a negligible performance hit.
443
444	  If unsure, say Y to enable cleancache
445
446config FRONTSWAP
447	bool "Enable frontswap to cache swap pages if tmem is present"
448	depends on SWAP
449	default n
450	help
451	  Frontswap is so named because it can be thought of as the opposite
452	  of a "backing" store for a swap device.  The data is stored into
453	  "transcendent memory", memory that is not directly accessible or
454	  addressable by the kernel and is of unknown and possibly
455	  time-varying size.  When space in transcendent memory is available,
456	  a significant swap I/O reduction may be achieved.  When none is
457	  available, all frontswap calls are reduced to a single pointer-
458	  compare-against-NULL resulting in a negligible performance hit
459	  and swap data is stored as normal on the matching swap device.
460
461	  If unsure, say Y to enable frontswap.
462