1# SPDX-License-Identifier: GPL-2.0-only
2
3menu "Memory Management options"
4
5#
6# For some reason microblaze and nios2 hard code SWAP=n.  Hopefully we can
7# add proper SWAP support to them, in which case this can be remove.
8#
9config ARCH_NO_SWAP
10	bool
11
12config ZPOOL
13	bool
14
15menuconfig SWAP
16	bool "Support for paging of anonymous memory (swap)"
17	depends on MMU && BLOCK && !ARCH_NO_SWAP
18	default y
19	help
20	  This option allows you to choose whether you want to have support
21	  for so called swap devices or swap files in your kernel that are
22	  used to provide more virtual memory than the actual RAM present
23	  in your computer.  If unsure say Y.
24
25config ZSWAP
26	bool "Compressed cache for swap pages (EXPERIMENTAL)"
27	depends on SWAP
28	select FRONTSWAP
29	select CRYPTO
30	select ZPOOL
31	help
32	  A lightweight compressed cache for swap pages.  It takes
33	  pages that are in the process of being swapped out and attempts to
34	  compress them into a dynamically allocated RAM-based memory pool.
35	  This can result in a significant I/O reduction on swap device and,
36	  in the case where decompressing from RAM is faster that swap device
37	  reads, can also improve workload performance.
38
39	  This is marked experimental because it is a new feature (as of
40	  v3.11) that interacts heavily with memory reclaim.  While these
41	  interactions don't cause any known issues on simple memory setups,
42	  they have not be fully explored on the large set of potential
43	  configurations and workloads that exist.
44
45config ZSWAP_DEFAULT_ON
46	bool "Enable the compressed cache for swap pages by default"
47	depends on ZSWAP
48	help
49	  If selected, the compressed cache for swap pages will be enabled
50	  at boot, otherwise it will be disabled.
51
52	  The selection made here can be overridden by using the kernel
53	  command line 'zswap.enabled=' option.
54
55choice
56	prompt "Default compressor"
57	depends on ZSWAP
58	default ZSWAP_COMPRESSOR_DEFAULT_LZO
59	help
60	  Selects the default compression algorithm for the compressed cache
61	  for swap pages.
62
63	  For an overview what kind of performance can be expected from
64	  a particular compression algorithm please refer to the benchmarks
65	  available at the following LWN page:
66	  https://lwn.net/Articles/751795/
67
68	  If in doubt, select 'LZO'.
69
70	  The selection made here can be overridden by using the kernel
71	  command line 'zswap.compressor=' option.
72
73config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE
74	bool "Deflate"
75	select CRYPTO_DEFLATE
76	help
77	  Use the Deflate algorithm as the default compression algorithm.
78
79config ZSWAP_COMPRESSOR_DEFAULT_LZO
80	bool "LZO"
81	select CRYPTO_LZO
82	help
83	  Use the LZO algorithm as the default compression algorithm.
84
85config ZSWAP_COMPRESSOR_DEFAULT_842
86	bool "842"
87	select CRYPTO_842
88	help
89	  Use the 842 algorithm as the default compression algorithm.
90
91config ZSWAP_COMPRESSOR_DEFAULT_LZ4
92	bool "LZ4"
93	select CRYPTO_LZ4
94	help
95	  Use the LZ4 algorithm as the default compression algorithm.
96
97config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC
98	bool "LZ4HC"
99	select CRYPTO_LZ4HC
100	help
101	  Use the LZ4HC algorithm as the default compression algorithm.
102
103config ZSWAP_COMPRESSOR_DEFAULT_ZSTD
104	bool "zstd"
105	select CRYPTO_ZSTD
106	help
107	  Use the zstd algorithm as the default compression algorithm.
108endchoice
109
110config ZSWAP_COMPRESSOR_DEFAULT
111       string
112       depends on ZSWAP
113       default "deflate" if ZSWAP_COMPRESSOR_DEFAULT_DEFLATE
114       default "lzo" if ZSWAP_COMPRESSOR_DEFAULT_LZO
115       default "842" if ZSWAP_COMPRESSOR_DEFAULT_842
116       default "lz4" if ZSWAP_COMPRESSOR_DEFAULT_LZ4
117       default "lz4hc" if ZSWAP_COMPRESSOR_DEFAULT_LZ4HC
118       default "zstd" if ZSWAP_COMPRESSOR_DEFAULT_ZSTD
119       default ""
120
121choice
122	prompt "Default allocator"
123	depends on ZSWAP
124	default ZSWAP_ZPOOL_DEFAULT_ZBUD
125	help
126	  Selects the default allocator for the compressed cache for
127	  swap pages.
128	  The default is 'zbud' for compatibility, however please do
129	  read the description of each of the allocators below before
130	  making a right choice.
131
132	  The selection made here can be overridden by using the kernel
133	  command line 'zswap.zpool=' option.
134
135config ZSWAP_ZPOOL_DEFAULT_ZBUD
136	bool "zbud"
137	select ZBUD
138	help
139	  Use the zbud allocator as the default allocator.
140
141config ZSWAP_ZPOOL_DEFAULT_Z3FOLD
142	bool "z3fold"
143	select Z3FOLD
144	help
145	  Use the z3fold allocator as the default allocator.
146
147config ZSWAP_ZPOOL_DEFAULT_ZSMALLOC
148	bool "zsmalloc"
149	select ZSMALLOC
150	help
151	  Use the zsmalloc allocator as the default allocator.
152endchoice
153
154config ZSWAP_ZPOOL_DEFAULT
155       string
156       depends on ZSWAP
157       default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD
158       default "z3fold" if ZSWAP_ZPOOL_DEFAULT_Z3FOLD
159       default "zsmalloc" if ZSWAP_ZPOOL_DEFAULT_ZSMALLOC
160       default ""
161
162config ZBUD
163	tristate "2:1 compression allocator (zbud)"
164	depends on ZSWAP
165	help
166	  A special purpose allocator for storing compressed pages.
167	  It is designed to store up to two compressed pages per physical
168	  page.  While this design limits storage density, it has simple and
169	  deterministic reclaim properties that make it preferable to a higher
170	  density approach when reclaim will be used.
171
172config Z3FOLD
173	tristate "3:1 compression allocator (z3fold)"
174	depends on ZSWAP
175	help
176	  A special purpose allocator for storing compressed pages.
177	  It is designed to store up to three compressed pages per physical
178	  page. It is a ZBUD derivative so the simplicity and determinism are
179	  still there.
180
181config ZSMALLOC
182	tristate
183	prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
184	depends on MMU
185	help
186	  zsmalloc is a slab-based memory allocator designed to store
187	  pages of various compression levels efficiently. It achieves
188	  the highest storage density with the least amount of fragmentation.
189
190config ZSMALLOC_STAT
191	bool "Export zsmalloc statistics"
192	depends on ZSMALLOC
193	select DEBUG_FS
194	help
195	  This option enables code in the zsmalloc to collect various
196	  statistics about what's happening in zsmalloc and exports that
197	  information to userspace via debugfs.
198	  If unsure, say N.
199
200menu "SLAB allocator options"
201
202choice
203	prompt "Choose SLAB allocator"
204	default SLUB
205	help
206	   This option allows to select a slab allocator.
207
208config SLAB
209	bool "SLAB"
210	depends on !PREEMPT_RT
211	select HAVE_HARDENED_USERCOPY_ALLOCATOR
212	help
213	  The regular slab allocator that is established and known to work
214	  well in all environments. It organizes cache hot objects in
215	  per cpu and per node queues.
216
217config SLUB
218	bool "SLUB (Unqueued Allocator)"
219	select HAVE_HARDENED_USERCOPY_ALLOCATOR
220	help
221	   SLUB is a slab allocator that minimizes cache line usage
222	   instead of managing queues of cached objects (SLAB approach).
223	   Per cpu caching is realized using slabs of objects instead
224	   of queues of objects. SLUB can use memory efficiently
225	   and has enhanced diagnostics. SLUB is the default choice for
226	   a slab allocator.
227
228config SLOB
229	depends on EXPERT
230	bool "SLOB (Simple Allocator)"
231	depends on !PREEMPT_RT
232	help
233	   SLOB replaces the stock allocator with a drastically simpler
234	   allocator. SLOB is generally more space efficient but
235	   does not perform as well on large systems.
236
237endchoice
238
239config SLAB_MERGE_DEFAULT
240	bool "Allow slab caches to be merged"
241	default y
242	depends on SLAB || SLUB
243	help
244	  For reduced kernel memory fragmentation, slab caches can be
245	  merged when they share the same size and other characteristics.
246	  This carries a risk of kernel heap overflows being able to
247	  overwrite objects from merged caches (and more easily control
248	  cache layout), which makes such heap attacks easier to exploit
249	  by attackers. By keeping caches unmerged, these kinds of exploits
250	  can usually only damage objects in the same cache. To disable
251	  merging at runtime, "slab_nomerge" can be passed on the kernel
252	  command line.
253
254config SLAB_FREELIST_RANDOM
255	bool "Randomize slab freelist"
256	depends on SLAB || SLUB
257	help
258	  Randomizes the freelist order used on creating new pages. This
259	  security feature reduces the predictability of the kernel slab
260	  allocator against heap overflows.
261
262config SLAB_FREELIST_HARDENED
263	bool "Harden slab freelist metadata"
264	depends on SLAB || SLUB
265	help
266	  Many kernel heap attacks try to target slab cache metadata and
267	  other infrastructure. This options makes minor performance
268	  sacrifices to harden the kernel slab allocator against common
269	  freelist exploit methods. Some slab implementations have more
270	  sanity-checking than others. This option is most effective with
271	  CONFIG_SLUB.
272
273config SLUB_STATS
274	default n
275	bool "Enable SLUB performance statistics"
276	depends on SLUB && SYSFS
277	help
278	  SLUB statistics are useful to debug SLUBs allocation behavior in
279	  order find ways to optimize the allocator. This should never be
280	  enabled for production use since keeping statistics slows down
281	  the allocator by a few percentage points. The slabinfo command
282	  supports the determination of the most active slabs to figure
283	  out which slabs are relevant to a particular load.
284	  Try running: slabinfo -DA
285
286config SLUB_CPU_PARTIAL
287	default y
288	depends on SLUB && SMP
289	bool "SLUB per cpu partial cache"
290	help
291	  Per cpu partial caches accelerate objects allocation and freeing
292	  that is local to a processor at the price of more indeterminism
293	  in the latency of the free. On overflow these caches will be cleared
294	  which requires the taking of locks that may cause latency spikes.
295	  Typically one would choose no for a realtime system.
296
297endmenu # SLAB allocator options
298
299config SHUFFLE_PAGE_ALLOCATOR
300	bool "Page allocator randomization"
301	default SLAB_FREELIST_RANDOM && ACPI_NUMA
302	help
303	  Randomization of the page allocator improves the average
304	  utilization of a direct-mapped memory-side-cache. See section
305	  5.2.27 Heterogeneous Memory Attribute Table (HMAT) in the ACPI
306	  6.2a specification for an example of how a platform advertises
307	  the presence of a memory-side-cache. There are also incidental
308	  security benefits as it reduces the predictability of page
309	  allocations to compliment SLAB_FREELIST_RANDOM, but the
310	  default granularity of shuffling on the "MAX_ORDER - 1" i.e,
311	  10th order of pages is selected based on cache utilization
312	  benefits on x86.
313
314	  While the randomization improves cache utilization it may
315	  negatively impact workloads on platforms without a cache. For
316	  this reason, by default, the randomization is enabled only
317	  after runtime detection of a direct-mapped memory-side-cache.
318	  Otherwise, the randomization may be force enabled with the
319	  'page_alloc.shuffle' kernel command line parameter.
320
321	  Say Y if unsure.
322
323config COMPAT_BRK
324	bool "Disable heap randomization"
325	default y
326	help
327	  Randomizing heap placement makes heap exploits harder, but it
328	  also breaks ancient binaries (including anything libc5 based).
329	  This option changes the bootup default to heap randomization
330	  disabled, and can be overridden at runtime by setting
331	  /proc/sys/kernel/randomize_va_space to 2.
332
333	  On non-ancient distros (post-2000 ones) N is usually a safe choice.
334
335config MMAP_ALLOW_UNINITIALIZED
336	bool "Allow mmapped anonymous memory to be uninitialized"
337	depends on EXPERT && !MMU
338	default n
339	help
340	  Normally, and according to the Linux spec, anonymous memory obtained
341	  from mmap() has its contents cleared before it is passed to
342	  userspace.  Enabling this config option allows you to request that
343	  mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
344	  providing a huge performance boost.  If this option is not enabled,
345	  then the flag will be ignored.
346
347	  This is taken advantage of by uClibc's malloc(), and also by
348	  ELF-FDPIC binfmt's brk and stack allocator.
349
350	  Because of the obvious security issues, this option should only be
351	  enabled on embedded devices where you control what is run in
352	  userspace.  Since that isn't generally a problem on no-MMU systems,
353	  it is normally safe to say Y here.
354
355	  See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
356
357config SELECT_MEMORY_MODEL
358	def_bool y
359	depends on ARCH_SELECT_MEMORY_MODEL
360
361choice
362	prompt "Memory model"
363	depends on SELECT_MEMORY_MODEL
364	default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT
365	default FLATMEM_MANUAL
366	help
367	  This option allows you to change some of the ways that
368	  Linux manages its memory internally. Most users will
369	  only have one option here selected by the architecture
370	  configuration. This is normal.
371
372config FLATMEM_MANUAL
373	bool "Flat Memory"
374	depends on !ARCH_SPARSEMEM_ENABLE || ARCH_FLATMEM_ENABLE
375	help
376	  This option is best suited for non-NUMA systems with
377	  flat address space. The FLATMEM is the most efficient
378	  system in terms of performance and resource consumption
379	  and it is the best option for smaller systems.
380
381	  For systems that have holes in their physical address
382	  spaces and for features like NUMA and memory hotplug,
383	  choose "Sparse Memory".
384
385	  If unsure, choose this option (Flat Memory) over any other.
386
387config SPARSEMEM_MANUAL
388	bool "Sparse Memory"
389	depends on ARCH_SPARSEMEM_ENABLE
390	help
391	  This will be the only option for some systems, including
392	  memory hot-plug systems.  This is normal.
393
394	  This option provides efficient support for systems with
395	  holes is their physical address space and allows memory
396	  hot-plug and hot-remove.
397
398	  If unsure, choose "Flat Memory" over this option.
399
400endchoice
401
402config SPARSEMEM
403	def_bool y
404	depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL
405
406config FLATMEM
407	def_bool y
408	depends on !SPARSEMEM || FLATMEM_MANUAL
409
410#
411# SPARSEMEM_EXTREME (which is the default) does some bootmem
412# allocations when sparse_init() is called.  If this cannot
413# be done on your architecture, select this option.  However,
414# statically allocating the mem_section[] array can potentially
415# consume vast quantities of .bss, so be careful.
416#
417# This option will also potentially produce smaller runtime code
418# with gcc 3.4 and later.
419#
420config SPARSEMEM_STATIC
421	bool
422
423#
424# Architecture platforms which require a two level mem_section in SPARSEMEM
425# must select this option. This is usually for architecture platforms with
426# an extremely sparse physical address space.
427#
428config SPARSEMEM_EXTREME
429	def_bool y
430	depends on SPARSEMEM && !SPARSEMEM_STATIC
431
432config SPARSEMEM_VMEMMAP_ENABLE
433	bool
434
435config SPARSEMEM_VMEMMAP
436	bool "Sparse Memory virtual memmap"
437	depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE
438	default y
439	help
440	  SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise
441	  pfn_to_page and page_to_pfn operations.  This is the most
442	  efficient option when sufficient kernel resources are available.
443
444config HAVE_MEMBLOCK_PHYS_MAP
445	bool
446
447config HAVE_FAST_GUP
448	depends on MMU
449	bool
450
451# Don't discard allocated memory used to track "memory" and "reserved" memblocks
452# after early boot, so it can still be used to test for validity of memory.
453# Also, memblocks are updated with memory hot(un)plug.
454config ARCH_KEEP_MEMBLOCK
455	bool
456
457# Keep arch NUMA mapping infrastructure post-init.
458config NUMA_KEEP_MEMINFO
459	bool
460
461config MEMORY_ISOLATION
462	bool
463
464# IORESOURCE_SYSTEM_RAM regions in the kernel resource tree that are marked
465# IORESOURCE_EXCLUSIVE cannot be mapped to user space, for example, via
466# /dev/mem.
467config EXCLUSIVE_SYSTEM_RAM
468	def_bool y
469	depends on !DEVMEM || STRICT_DEVMEM
470
471#
472# Only be set on architectures that have completely implemented memory hotplug
473# feature. If you are not sure, don't touch it.
474#
475config HAVE_BOOTMEM_INFO_NODE
476	def_bool n
477
478config ARCH_ENABLE_MEMORY_HOTPLUG
479	bool
480
481config ARCH_ENABLE_MEMORY_HOTREMOVE
482	bool
483
484# eventually, we can have this option just 'select SPARSEMEM'
485menuconfig MEMORY_HOTPLUG
486	bool "Memory hotplug"
487	select MEMORY_ISOLATION
488	depends on SPARSEMEM
489	depends on ARCH_ENABLE_MEMORY_HOTPLUG
490	depends on 64BIT
491	select NUMA_KEEP_MEMINFO if NUMA
492
493if MEMORY_HOTPLUG
494
495config MEMORY_HOTPLUG_DEFAULT_ONLINE
496	bool "Online the newly added memory blocks by default"
497	depends on MEMORY_HOTPLUG
498	help
499	  This option sets the default policy setting for memory hotplug
500	  onlining policy (/sys/devices/system/memory/auto_online_blocks) which
501	  determines what happens to newly added memory regions. Policy setting
502	  can always be changed at runtime.
503	  See Documentation/admin-guide/mm/memory-hotplug.rst for more information.
504
505	  Say Y here if you want all hot-plugged memory blocks to appear in
506	  'online' state by default.
507	  Say N here if you want the default policy to keep all hot-plugged
508	  memory blocks in 'offline' state.
509
510config MEMORY_HOTREMOVE
511	bool "Allow for memory hot remove"
512	select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
513	depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
514	depends on MIGRATION
515
516config MHP_MEMMAP_ON_MEMORY
517	def_bool y
518	depends on MEMORY_HOTPLUG && SPARSEMEM_VMEMMAP
519	depends on ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
520
521endif # MEMORY_HOTPLUG
522
523# Heavily threaded applications may benefit from splitting the mm-wide
524# page_table_lock, so that faults on different parts of the user address
525# space can be handled with less contention: split it at this NR_CPUS.
526# Default to 4 for wider testing, though 8 might be more appropriate.
527# ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
528# PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
529# SPARC32 allocates multiple pte tables within a single page, and therefore
530# a per-page lock leads to problems when multiple tables need to be locked
531# at the same time (e.g. copy_page_range()).
532# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page.
533#
534config SPLIT_PTLOCK_CPUS
535	int
536	default "999999" if !MMU
537	default "999999" if ARM && !CPU_CACHE_VIPT
538	default "999999" if PARISC && !PA20
539	default "999999" if SPARC32
540	default "4"
541
542config ARCH_ENABLE_SPLIT_PMD_PTLOCK
543	bool
544
545#
546# support for memory balloon
547config MEMORY_BALLOON
548	bool
549
550#
551# support for memory balloon compaction
552config BALLOON_COMPACTION
553	bool "Allow for balloon memory compaction/migration"
554	def_bool y
555	depends on COMPACTION && MEMORY_BALLOON
556	help
557	  Memory fragmentation introduced by ballooning might reduce
558	  significantly the number of 2MB contiguous memory blocks that can be
559	  used within a guest, thus imposing performance penalties associated
560	  with the reduced number of transparent huge pages that could be used
561	  by the guest workload. Allowing the compaction & migration for memory
562	  pages enlisted as being part of memory balloon devices avoids the
563	  scenario aforementioned and helps improving memory defragmentation.
564
565#
566# support for memory compaction
567config COMPACTION
568	bool "Allow for memory compaction"
569	def_bool y
570	select MIGRATION
571	depends on MMU
572	help
573	  Compaction is the only memory management component to form
574	  high order (larger physically contiguous) memory blocks
575	  reliably. The page allocator relies on compaction heavily and
576	  the lack of the feature can lead to unexpected OOM killer
577	  invocations for high order memory requests. You shouldn't
578	  disable this option unless there really is a strong reason for
579	  it and then we would be really interested to hear about that at
580	  linux-mm@kvack.org.
581
582#
583# support for free page reporting
584config PAGE_REPORTING
585	bool "Free page reporting"
586	def_bool n
587	help
588	  Free page reporting allows for the incremental acquisition of
589	  free pages from the buddy allocator for the purpose of reporting
590	  those pages to another entity, such as a hypervisor, so that the
591	  memory can be freed within the host for other uses.
592
593#
594# support for page migration
595#
596config MIGRATION
597	bool "Page migration"
598	def_bool y
599	depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU
600	help
601	  Allows the migration of the physical location of pages of processes
602	  while the virtual addresses are not changed. This is useful in
603	  two situations. The first is on NUMA systems to put pages nearer
604	  to the processors accessing. The second is when allocating huge
605	  pages as migration can relocate pages to satisfy a huge page
606	  allocation instead of reclaiming.
607
608config DEVICE_MIGRATION
609	def_bool MIGRATION && ZONE_DEVICE
610
611config ARCH_ENABLE_HUGEPAGE_MIGRATION
612	bool
613
614config ARCH_ENABLE_THP_MIGRATION
615	bool
616
617config HUGETLB_PAGE_SIZE_VARIABLE
618	def_bool n
619	help
620	  Allows the pageblock_order value to be dynamic instead of just standard
621	  HUGETLB_PAGE_ORDER when there are multiple HugeTLB page sizes available
622	  on a platform.
623
624	  Note that the pageblock_order cannot exceed MAX_ORDER - 1 and will be
625	  clamped down to MAX_ORDER - 1.
626
627config CONTIG_ALLOC
628	def_bool (MEMORY_ISOLATION && COMPACTION) || CMA
629
630config PHYS_ADDR_T_64BIT
631	def_bool 64BIT
632
633config BOUNCE
634	bool "Enable bounce buffers"
635	default y
636	depends on BLOCK && MMU && HIGHMEM
637	help
638	  Enable bounce buffers for devices that cannot access the full range of
639	  memory available to the CPU. Enabled by default when HIGHMEM is
640	  selected, but you may say n to override this.
641
642config VIRT_TO_BUS
643	bool
644	help
645	  An architecture should select this if it implements the
646	  deprecated interface virt_to_bus().  All new architectures
647	  should probably not select this.
648
649
650config MMU_NOTIFIER
651	bool
652	select SRCU
653	select INTERVAL_TREE
654
655config KSM
656	bool "Enable KSM for page merging"
657	depends on MMU
658	select XXHASH
659	help
660	  Enable Kernel Samepage Merging: KSM periodically scans those areas
661	  of an application's address space that an app has advised may be
662	  mergeable.  When it finds pages of identical content, it replaces
663	  the many instances by a single page with that content, so
664	  saving memory until one or another app needs to modify the content.
665	  Recommended for use with KVM, or with other duplicative applications.
666	  See Documentation/vm/ksm.rst for more information: KSM is inactive
667	  until a program has madvised that an area is MADV_MERGEABLE, and
668	  root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set).
669
670config DEFAULT_MMAP_MIN_ADDR
671	int "Low address space to protect from user allocation"
672	depends on MMU
673	default 4096
674	help
675	  This is the portion of low virtual memory which should be protected
676	  from userspace allocation.  Keeping a user from writing to low pages
677	  can help reduce the impact of kernel NULL pointer bugs.
678
679	  For most ia64, ppc64 and x86 users with lots of address space
680	  a value of 65536 is reasonable and should cause no problems.
681	  On arm and other archs it should not be higher than 32768.
682	  Programs which use vm86 functionality or have some need to map
683	  this low address space will need CAP_SYS_RAWIO or disable this
684	  protection by setting the value to 0.
685
686	  This value can be changed after boot using the
687	  /proc/sys/vm/mmap_min_addr tunable.
688
689config ARCH_SUPPORTS_MEMORY_FAILURE
690	bool
691
692config MEMORY_FAILURE
693	depends on MMU
694	depends on ARCH_SUPPORTS_MEMORY_FAILURE
695	bool "Enable recovery from hardware memory errors"
696	select MEMORY_ISOLATION
697	select RAS
698	help
699	  Enables code to recover from some memory failures on systems
700	  with MCA recovery. This allows a system to continue running
701	  even when some of its memory has uncorrected errors. This requires
702	  special hardware support and typically ECC memory.
703
704config HWPOISON_INJECT
705	tristate "HWPoison pages injector"
706	depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
707	select PROC_PAGE_MONITOR
708
709config NOMMU_INITIAL_TRIM_EXCESS
710	int "Turn on mmap() excess space trimming before booting"
711	depends on !MMU
712	default 1
713	help
714	  The NOMMU mmap() frequently needs to allocate large contiguous chunks
715	  of memory on which to store mappings, but it can only ask the system
716	  allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently
717	  more than it requires.  To deal with this, mmap() is able to trim off
718	  the excess and return it to the allocator.
719
720	  If trimming is enabled, the excess is trimmed off and returned to the
721	  system allocator, which can cause extra fragmentation, particularly
722	  if there are a lot of transient processes.
723
724	  If trimming is disabled, the excess is kept, but not used, which for
725	  long-term mappings means that the space is wasted.
726
727	  Trimming can be dynamically controlled through a sysctl option
728	  (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of
729	  excess pages there must be before trimming should occur, or zero if
730	  no trimming is to occur.
731
732	  This option specifies the initial value of this option.  The default
733	  of 1 says that all excess pages should be trimmed.
734
735	  See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
736
737config ARCH_WANT_GENERAL_HUGETLB
738	bool
739
740config ARCH_WANTS_THP_SWAP
741	def_bool n
742
743menuconfig TRANSPARENT_HUGEPAGE
744	bool "Transparent Hugepage Support"
745	depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE && !PREEMPT_RT
746	select COMPACTION
747	select XARRAY_MULTI
748	help
749	  Transparent Hugepages allows the kernel to use huge pages and
750	  huge tlb transparently to the applications whenever possible.
751	  This feature can improve computing performance to certain
752	  applications by speeding up page faults during memory
753	  allocation, by reducing the number of tlb misses and by speeding
754	  up the pagetable walking.
755
756	  If memory constrained on embedded, you may want to say N.
757
758if TRANSPARENT_HUGEPAGE
759
760choice
761	prompt "Transparent Hugepage Support sysfs defaults"
762	depends on TRANSPARENT_HUGEPAGE
763	default TRANSPARENT_HUGEPAGE_ALWAYS
764	help
765	  Selects the sysfs defaults for Transparent Hugepage Support.
766
767	config TRANSPARENT_HUGEPAGE_ALWAYS
768		bool "always"
769	help
770	  Enabling Transparent Hugepage always, can increase the
771	  memory footprint of applications without a guaranteed
772	  benefit but it will work automatically for all applications.
773
774	config TRANSPARENT_HUGEPAGE_MADVISE
775		bool "madvise"
776	help
777	  Enabling Transparent Hugepage madvise, will only provide a
778	  performance improvement benefit to the applications using
779	  madvise(MADV_HUGEPAGE) but it won't risk to increase the
780	  memory footprint of applications without a guaranteed
781	  benefit.
782endchoice
783
784config THP_SWAP
785	def_bool y
786	depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP
787	help
788	  Swap transparent huge pages in one piece, without splitting.
789	  XXX: For now, swap cluster backing transparent huge page
790	  will be split after swapout.
791
792	  For selection by architectures with reasonable THP sizes.
793
794config READ_ONLY_THP_FOR_FS
795	bool "Read-only THP for filesystems (EXPERIMENTAL)"
796	depends on TRANSPARENT_HUGEPAGE && SHMEM
797
798	help
799	  Allow khugepaged to put read-only file-backed pages in THP.
800
801	  This is marked experimental because it is a new feature. Write
802	  support of file THPs will be developed in the next few release
803	  cycles.
804
805endif # TRANSPARENT_HUGEPAGE
806
807#
808# UP and nommu archs use km based percpu allocator
809#
810config NEED_PER_CPU_KM
811	depends on !SMP || !MMU
812	bool
813	default y
814
815config NEED_PER_CPU_EMBED_FIRST_CHUNK
816	bool
817
818config NEED_PER_CPU_PAGE_FIRST_CHUNK
819	bool
820
821config USE_PERCPU_NUMA_NODE_ID
822	bool
823
824config HAVE_SETUP_PER_CPU_AREA
825	bool
826
827config FRONTSWAP
828	bool
829
830config CMA
831	bool "Contiguous Memory Allocator"
832	depends on MMU
833	select MIGRATION
834	select MEMORY_ISOLATION
835	help
836	  This enables the Contiguous Memory Allocator which allows other
837	  subsystems to allocate big physically-contiguous blocks of memory.
838	  CMA reserves a region of memory and allows only movable pages to
839	  be allocated from it. This way, the kernel can use the memory for
840	  pagecache and when a subsystem requests for contiguous area, the
841	  allocated pages are migrated away to serve the contiguous request.
842
843	  If unsure, say "n".
844
845config CMA_DEBUG
846	bool "CMA debug messages (DEVELOPMENT)"
847	depends on DEBUG_KERNEL && CMA
848	help
849	  Turns on debug messages in CMA.  This produces KERN_DEBUG
850	  messages for every CMA call as well as various messages while
851	  processing calls such as dma_alloc_from_contiguous().
852	  This option does not affect warning and error messages.
853
854config CMA_DEBUGFS
855	bool "CMA debugfs interface"
856	depends on CMA && DEBUG_FS
857	help
858	  Turns on the DebugFS interface for CMA.
859
860config CMA_SYSFS
861	bool "CMA information through sysfs interface"
862	depends on CMA && SYSFS
863	help
864	  This option exposes some sysfs attributes to get information
865	  from CMA.
866
867config CMA_AREAS
868	int "Maximum count of the CMA areas"
869	depends on CMA
870	default 19 if NUMA
871	default 7
872	help
873	  CMA allows to create CMA areas for particular purpose, mainly,
874	  used as device private area. This parameter sets the maximum
875	  number of CMA area in the system.
876
877	  If unsure, leave the default value "7" in UMA and "19" in NUMA.
878
879config MEM_SOFT_DIRTY
880	bool "Track memory changes"
881	depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS
882	select PROC_PAGE_MONITOR
883	help
884	  This option enables memory changes tracking by introducing a
885	  soft-dirty bit on pte-s. This bit it set when someone writes
886	  into a page just as regular dirty bit, but unlike the latter
887	  it can be cleared by hands.
888
889	  See Documentation/admin-guide/mm/soft-dirty.rst for more details.
890
891config GENERIC_EARLY_IOREMAP
892	bool
893
894config STACK_MAX_DEFAULT_SIZE_MB
895	int "Default maximum user stack size for 32-bit processes (MB)"
896	default 100
897	range 8 2048
898	depends on STACK_GROWSUP && (!64BIT || COMPAT)
899	help
900	  This is the maximum stack size in Megabytes in the VM layout of 32-bit
901	  user processes when the stack grows upwards (currently only on parisc
902	  arch) when the RLIMIT_STACK hard limit is unlimited.
903
904	  A sane initial value is 100 MB.
905
906config DEFERRED_STRUCT_PAGE_INIT
907	bool "Defer initialisation of struct pages to kthreads"
908	depends on SPARSEMEM
909	depends on !NEED_PER_CPU_KM
910	depends on 64BIT
911	select PADATA
912	help
913	  Ordinarily all struct pages are initialised during early boot in a
914	  single thread. On very large machines this can take a considerable
915	  amount of time. If this option is set, large machines will bring up
916	  a subset of memmap at boot and then initialise the rest in parallel.
917	  This has a potential performance impact on tasks running early in the
918	  lifetime of the system until these kthreads finish the
919	  initialisation.
920
921config PAGE_IDLE_FLAG
922	bool
923	select PAGE_EXTENSION if !64BIT
924	help
925	  This adds PG_idle and PG_young flags to 'struct page'.  PTE Accessed
926	  bit writers can set the state of the bit in the flags so that PTE
927	  Accessed bit readers may avoid disturbance.
928
929config IDLE_PAGE_TRACKING
930	bool "Enable idle page tracking"
931	depends on SYSFS && MMU
932	select PAGE_IDLE_FLAG
933	help
934	  This feature allows to estimate the amount of user pages that have
935	  not been touched during a given period of time. This information can
936	  be useful to tune memory cgroup limits and/or for job placement
937	  within a compute cluster.
938
939	  See Documentation/admin-guide/mm/idle_page_tracking.rst for
940	  more details.
941
942config ARCH_HAS_CACHE_LINE_SIZE
943	bool
944
945config ARCH_HAS_CURRENT_STACK_POINTER
946	bool
947	help
948	  In support of HARDENED_USERCOPY performing stack variable lifetime
949	  checking, an architecture-agnostic way to find the stack pointer
950	  is needed. Once an architecture defines an unsigned long global
951	  register alias named "current_stack_pointer", this config can be
952	  selected.
953
954config ARCH_HAS_VM_GET_PAGE_PROT
955	bool
956
957config ARCH_HAS_PTE_DEVMAP
958	bool
959
960config ARCH_HAS_ZONE_DMA_SET
961	bool
962
963config ZONE_DMA
964	bool "Support DMA zone" if ARCH_HAS_ZONE_DMA_SET
965	default y if ARM64 || X86
966
967config ZONE_DMA32
968	bool "Support DMA32 zone" if ARCH_HAS_ZONE_DMA_SET
969	depends on !X86_32
970	default y if ARM64
971
972config ZONE_DEVICE
973	bool "Device memory (pmem, HMM, etc...) hotplug support"
974	depends on MEMORY_HOTPLUG
975	depends on MEMORY_HOTREMOVE
976	depends on SPARSEMEM_VMEMMAP
977	depends on ARCH_HAS_PTE_DEVMAP
978	select XARRAY_MULTI
979
980	help
981	  Device memory hotplug support allows for establishing pmem,
982	  or other device driver discovered memory regions, in the
983	  memmap. This allows pfn_to_page() lookups of otherwise
984	  "device-physical" addresses which is needed for using a DAX
985	  mapping in an O_DIRECT operation, among other things.
986
987	  If FS_DAX is enabled, then say Y.
988
989#
990# Helpers to mirror range of the CPU page tables of a process into device page
991# tables.
992#
993config HMM_MIRROR
994	bool
995	depends on MMU
996
997config DEVICE_PRIVATE
998	bool "Unaddressable device memory (GPU memory, ...)"
999	depends on ZONE_DEVICE
1000
1001	help
1002	  Allows creation of struct pages to represent unaddressable device
1003	  memory; i.e., memory that is only accessible from the device (or
1004	  group of devices). You likely also want to select HMM_MIRROR.
1005
1006config VMAP_PFN
1007	bool
1008
1009config ARCH_USES_HIGH_VMA_FLAGS
1010	bool
1011config ARCH_HAS_PKEYS
1012	bool
1013
1014config VM_EVENT_COUNTERS
1015	default y
1016	bool "Enable VM event counters for /proc/vmstat" if EXPERT
1017	help
1018	  VM event counters are needed for event counts to be shown.
1019	  This option allows the disabling of the VM event counters
1020	  on EXPERT systems.  /proc/vmstat will only show page counts
1021	  if VM event counters are disabled.
1022
1023config PERCPU_STATS
1024	bool "Collect percpu memory statistics"
1025	help
1026	  This feature collects and exposes statistics via debugfs. The
1027	  information includes global and per chunk statistics, which can
1028	  be used to help understand percpu memory usage.
1029
1030config GUP_TEST
1031	bool "Enable infrastructure for get_user_pages()-related unit tests"
1032	depends on DEBUG_FS
1033	help
1034	  Provides /sys/kernel/debug/gup_test, which in turn provides a way
1035	  to make ioctl calls that can launch kernel-based unit tests for
1036	  the get_user_pages*() and pin_user_pages*() family of API calls.
1037
1038	  These tests include benchmark testing of the _fast variants of
1039	  get_user_pages*() and pin_user_pages*(), as well as smoke tests of
1040	  the non-_fast variants.
1041
1042	  There is also a sub-test that allows running dump_page() on any
1043	  of up to eight pages (selected by command line args) within the
1044	  range of user-space addresses. These pages are either pinned via
1045	  pin_user_pages*(), or pinned via get_user_pages*(), as specified
1046	  by other command line arguments.
1047
1048	  See tools/testing/selftests/vm/gup_test.c
1049
1050comment "GUP_TEST needs to have DEBUG_FS enabled"
1051	depends on !GUP_TEST && !DEBUG_FS
1052
1053config GUP_GET_PTE_LOW_HIGH
1054	bool
1055
1056config ARCH_HAS_PTE_SPECIAL
1057	bool
1058
1059#
1060# Some architectures require a special hugepage directory format that is
1061# required to support multiple hugepage sizes. For example a4fe3ce76
1062# "powerpc/mm: Allow more flexible layouts for hugepage pagetables"
1063# introduced it on powerpc.  This allows for a more flexible hugepage
1064# pagetable layouts.
1065#
1066config ARCH_HAS_HUGEPD
1067	bool
1068
1069config MAPPING_DIRTY_HELPERS
1070        bool
1071
1072config KMAP_LOCAL
1073	bool
1074
1075config KMAP_LOCAL_NON_LINEAR_PTE_ARRAY
1076	bool
1077
1078# struct io_mapping based helper.  Selected by drivers that need them
1079config IO_MAPPING
1080	bool
1081
1082config SECRETMEM
1083	def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED
1084
1085config ANON_VMA_NAME
1086	bool "Anonymous VMA name support"
1087	depends on PROC_FS && ADVISE_SYSCALLS && MMU
1088
1089	help
1090	  Allow naming anonymous virtual memory areas.
1091
1092	  This feature allows assigning names to virtual memory areas. Assigned
1093	  names can be later retrieved from /proc/pid/maps and /proc/pid/smaps
1094	  and help identifying individual anonymous memory areas.
1095	  Assigning a name to anonymous virtual memory area might prevent that
1096	  area from being merged with adjacent virtual memory areas due to the
1097	  difference in their name.
1098
1099config USERFAULTFD
1100	bool "Enable userfaultfd() system call"
1101	depends on MMU
1102	help
1103	  Enable the userfaultfd() system call that allows to intercept and
1104	  handle page faults in userland.
1105
1106config HAVE_ARCH_USERFAULTFD_WP
1107	bool
1108	help
1109	  Arch has userfaultfd write protection support
1110
1111config HAVE_ARCH_USERFAULTFD_MINOR
1112	bool
1113	help
1114	  Arch has userfaultfd minor fault support
1115
1116config PTE_MARKER
1117	bool
1118
1119	help
1120	  Allows to create marker PTEs for file-backed memory.
1121
1122config PTE_MARKER_UFFD_WP
1123	bool "Userfaultfd write protection support for shmem/hugetlbfs"
1124	default y
1125	depends on HAVE_ARCH_USERFAULTFD_WP
1126	select PTE_MARKER
1127
1128	help
1129	  Allows to create marker PTEs for userfaultfd write protection
1130	  purposes.  It is required to enable userfaultfd write protection on
1131	  file-backed memory types like shmem and hugetlbfs.
1132
1133source "mm/damon/Kconfig"
1134
1135endmenu
1136