• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
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 HYPERHOLD_FILE_LRU
67	bool "Enable HyperHold FILE LRU"
68	depends on HYPERHOLD && MEMCG
69	select HYPERHOLD_MEMCG
70	default n
71	help
72	  File-LRU is a mechanism that put file page in global lru list,
73	  and anon page in memcg lru list(if MEMCG is enable), what's
74	  more, recliam of anonymous pages and file page are separated.
75
76config HYPERHOLD_MEMCG
77	bool "Enable Memcg Management in HyperHold"
78	depends on HYPERHOLD && MEMCG
79	help
80	  Add more attributes in memory cgroup, these attribute is used
81	  to show information, shrink memory, swapin page and so on.
82
83config HYPERHOLD_ZSWAPD
84	bool "Enable zswapd thread to reclaim anon pages in background"
85	depends on HYPERHOLD && ZRAM
86	default n
87	help
88	  zswapd is a kernel thread that reclaim anonymous pages in the
89	  background. When the use of swap pages reaches the watermark
90	  and the refault of anonymous pages is high, the content of
91	  zram will exchanged to eswap by a certain percentage.
92
93config DISCONTIGMEM
94	def_bool y
95	depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL
96
97config SPARSEMEM
98	def_bool y
99	depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL
100
101config FLATMEM
102	def_bool y
103	depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL
104
105config FLAT_NODE_MEM_MAP
106	def_bool y
107	depends on !SPARSEMEM
108
109#
110# Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's
111# to represent different areas of memory.  This variable allows
112# those dependencies to exist individually.
113#
114config NEED_MULTIPLE_NODES
115	def_bool y
116	depends on DISCONTIGMEM || NUMA
117
118#
119# SPARSEMEM_EXTREME (which is the default) does some bootmem
120# allocations when sparse_init() is called.  If this cannot
121# be done on your architecture, select this option.  However,
122# statically allocating the mem_section[] array can potentially
123# consume vast quantities of .bss, so be careful.
124#
125# This option will also potentially produce smaller runtime code
126# with gcc 3.4 and later.
127#
128config SPARSEMEM_STATIC
129	bool
130
131#
132# Architecture platforms which require a two level mem_section in SPARSEMEM
133# must select this option. This is usually for architecture platforms with
134# an extremely sparse physical address space.
135#
136config SPARSEMEM_EXTREME
137	def_bool y
138	depends on SPARSEMEM && !SPARSEMEM_STATIC
139
140config SPARSEMEM_VMEMMAP_ENABLE
141	bool
142
143config SPARSEMEM_VMEMMAP
144	bool "Sparse Memory virtual memmap"
145	depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE
146	default y
147	help
148	  SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise
149	  pfn_to_page and page_to_pfn operations.  This is the most
150	  efficient option when sufficient kernel resources are available.
151
152config HAVE_MEMBLOCK_PHYS_MAP
153	bool
154
155config HAVE_FAST_GUP
156	depends on MMU
157	bool
158
159config HOLES_IN_ZONE
160	bool
161
162# Don't discard allocated memory used to track "memory" and "reserved" memblocks
163# after early boot, so it can still be used to test for validity of memory.
164# Also, memblocks are updated with memory hot(un)plug.
165config ARCH_KEEP_MEMBLOCK
166	bool
167
168# Keep arch NUMA mapping infrastructure post-init.
169config NUMA_KEEP_MEMINFO
170	bool
171
172config MEMORY_ISOLATION
173	bool
174
175#
176# Only be set on architectures that have completely implemented memory hotplug
177# feature. If you are not sure, don't touch it.
178#
179config HAVE_BOOTMEM_INFO_NODE
180	def_bool n
181
182# eventually, we can have this option just 'select SPARSEMEM'
183config MEMORY_HOTPLUG
184	bool "Allow for memory hot-add"
185	select MEMORY_ISOLATION
186	depends on SPARSEMEM || X86_64_ACPI_NUMA
187	depends on ARCH_ENABLE_MEMORY_HOTPLUG
188	depends on 64BIT || BROKEN
189	select NUMA_KEEP_MEMINFO if NUMA
190
191config MEMORY_HOTPLUG_SPARSE
192	def_bool y
193	depends on SPARSEMEM && MEMORY_HOTPLUG
194
195config MEMORY_HOTPLUG_DEFAULT_ONLINE
196	bool "Online the newly added memory blocks by default"
197	depends on MEMORY_HOTPLUG
198	help
199	  This option sets the default policy setting for memory hotplug
200	  onlining policy (/sys/devices/system/memory/auto_online_blocks) which
201	  determines what happens to newly added memory regions. Policy setting
202	  can always be changed at runtime.
203	  See Documentation/admin-guide/mm/memory-hotplug.rst for more information.
204
205	  Say Y here if you want all hot-plugged memory blocks to appear in
206	  'online' state by default.
207	  Say N here if you want the default policy to keep all hot-plugged
208	  memory blocks in 'offline' state.
209
210config MEMORY_HOTREMOVE
211	bool "Allow for memory hot remove"
212	select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
213	depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
214	depends on MIGRATION
215
216# Heavily threaded applications may benefit from splitting the mm-wide
217# page_table_lock, so that faults on different parts of the user address
218# space can be handled with less contention: split it at this NR_CPUS.
219# Default to 4 for wider testing, though 8 might be more appropriate.
220# ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
221# PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
222# SPARC32 allocates multiple pte tables within a single page, and therefore
223# a per-page lock leads to problems when multiple tables need to be locked
224# at the same time (e.g. copy_page_range()).
225# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page.
226#
227config SPLIT_PTLOCK_CPUS
228	int
229	default "999999" if !MMU
230	default "999999" if ARM && !CPU_CACHE_VIPT
231	default "999999" if PARISC && !PA20
232	default "999999" if SPARC32
233	default "4"
234
235config ARCH_ENABLE_SPLIT_PMD_PTLOCK
236	bool
237
238#
239# support for memory balloon
240config MEMORY_BALLOON
241	bool
242
243#
244# support for memory balloon compaction
245config BALLOON_COMPACTION
246	bool "Allow for balloon memory compaction/migration"
247	def_bool y
248	depends on COMPACTION && MEMORY_BALLOON
249	help
250	  Memory fragmentation introduced by ballooning might reduce
251	  significantly the number of 2MB contiguous memory blocks that can be
252	  used within a guest, thus imposing performance penalties associated
253	  with the reduced number of transparent huge pages that could be used
254	  by the guest workload. Allowing the compaction & migration for memory
255	  pages enlisted as being part of memory balloon devices avoids the
256	  scenario aforementioned and helps improving memory defragmentation.
257
258#
259# support for memory compaction
260config COMPACTION
261	bool "Allow for memory compaction"
262	def_bool y
263	select MIGRATION
264	depends on MMU
265	help
266	  Compaction is the only memory management component to form
267	  high order (larger physically contiguous) memory blocks
268	  reliably. The page allocator relies on compaction heavily and
269	  the lack of the feature can lead to unexpected OOM killer
270	  invocations for high order memory requests. You shouldn't
271	  disable this option unless there really is a strong reason for
272	  it and then we would be really interested to hear about that at
273	  linux-mm@kvack.org.
274
275#
276# support for free page reporting
277config PAGE_REPORTING
278	bool "Free page reporting"
279	def_bool n
280	help
281	  Free page reporting allows for the incremental acquisition of
282	  free pages from the buddy allocator for the purpose of reporting
283	  those pages to another entity, such as a hypervisor, so that the
284	  memory can be freed within the host for other uses.
285
286#
287# support for page migration
288#
289config MIGRATION
290	bool "Page migration"
291	def_bool y
292	depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU
293	help
294	  Allows the migration of the physical location of pages of processes
295	  while the virtual addresses are not changed. This is useful in
296	  two situations. The first is on NUMA systems to put pages nearer
297	  to the processors accessing. The second is when allocating huge
298	  pages as migration can relocate pages to satisfy a huge page
299	  allocation instead of reclaiming.
300
301config ARCH_ENABLE_HUGEPAGE_MIGRATION
302	bool
303
304config ARCH_ENABLE_THP_MIGRATION
305	bool
306
307config CONTIG_ALLOC
308	def_bool (MEMORY_ISOLATION && COMPACTION) || CMA
309
310config PHYS_ADDR_T_64BIT
311	def_bool 64BIT
312
313config BOUNCE
314	bool "Enable bounce buffers"
315	default y
316	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
317	help
318	  Enable bounce buffers for devices that cannot access
319	  the full range of memory available to the CPU. Enabled
320	  by default when ZONE_DMA or HIGHMEM is selected, but you
321	  may say n to override this.
322
323config VIRT_TO_BUS
324	bool
325	help
326	  An architecture should select this if it implements the
327	  deprecated interface virt_to_bus().  All new architectures
328	  should probably not select this.
329
330
331config MMU_NOTIFIER
332	bool
333	select SRCU
334	select INTERVAL_TREE
335
336config KSM
337	bool "Enable KSM for page merging"
338	depends on MMU
339	select XXHASH
340	help
341	  Enable Kernel Samepage Merging: KSM periodically scans those areas
342	  of an application's address space that an app has advised may be
343	  mergeable.  When it finds pages of identical content, it replaces
344	  the many instances by a single page with that content, so
345	  saving memory until one or another app needs to modify the content.
346	  Recommended for use with KVM, or with other duplicative applications.
347	  See Documentation/vm/ksm.rst for more information: KSM is inactive
348	  until a program has madvised that an area is MADV_MERGEABLE, and
349	  root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set).
350
351config DEFAULT_MMAP_MIN_ADDR
352	int "Low address space to protect from user allocation"
353	depends on MMU
354	default 4096
355	help
356	  This is the portion of low virtual memory which should be protected
357	  from userspace allocation.  Keeping a user from writing to low pages
358	  can help reduce the impact of kernel NULL pointer bugs.
359
360	  For most ia64, ppc64 and x86 users with lots of address space
361	  a value of 65536 is reasonable and should cause no problems.
362	  On arm and other archs it should not be higher than 32768.
363	  Programs which use vm86 functionality or have some need to map
364	  this low address space will need CAP_SYS_RAWIO or disable this
365	  protection by setting the value to 0.
366
367	  This value can be changed after boot using the
368	  /proc/sys/vm/mmap_min_addr tunable.
369
370config ARCH_SUPPORTS_MEMORY_FAILURE
371	bool
372
373config MEMORY_FAILURE
374	depends on MMU
375	depends on ARCH_SUPPORTS_MEMORY_FAILURE
376	bool "Enable recovery from hardware memory errors"
377	select MEMORY_ISOLATION
378	select RAS
379	help
380	  Enables code to recover from some memory failures on systems
381	  with MCA recovery. This allows a system to continue running
382	  even when some of its memory has uncorrected errors. This requires
383	  special hardware support and typically ECC memory.
384
385config HWPOISON_INJECT
386	tristate "HWPoison pages injector"
387	depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
388	select PROC_PAGE_MONITOR
389
390config NOMMU_INITIAL_TRIM_EXCESS
391	int "Turn on mmap() excess space trimming before booting"
392	depends on !MMU
393	default 1
394	help
395	  The NOMMU mmap() frequently needs to allocate large contiguous chunks
396	  of memory on which to store mappings, but it can only ask the system
397	  allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently
398	  more than it requires.  To deal with this, mmap() is able to trim off
399	  the excess and return it to the allocator.
400
401	  If trimming is enabled, the excess is trimmed off and returned to the
402	  system allocator, which can cause extra fragmentation, particularly
403	  if there are a lot of transient processes.
404
405	  If trimming is disabled, the excess is kept, but not used, which for
406	  long-term mappings means that the space is wasted.
407
408	  Trimming can be dynamically controlled through a sysctl option
409	  (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of
410	  excess pages there must be before trimming should occur, or zero if
411	  no trimming is to occur.
412
413	  This option specifies the initial value of this option.  The default
414	  of 1 says that all excess pages should be trimmed.
415
416	  See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
417
418config TRANSPARENT_HUGEPAGE
419	bool "Transparent Hugepage Support"
420	depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE
421	select COMPACTION
422	select XARRAY_MULTI
423	help
424	  Transparent Hugepages allows the kernel to use huge pages and
425	  huge tlb transparently to the applications whenever possible.
426	  This feature can improve computing performance to certain
427	  applications by speeding up page faults during memory
428	  allocation, by reducing the number of tlb misses and by speeding
429	  up the pagetable walking.
430
431	  If memory constrained on embedded, you may want to say N.
432
433choice
434	prompt "Transparent Hugepage Support sysfs defaults"
435	depends on TRANSPARENT_HUGEPAGE
436	default TRANSPARENT_HUGEPAGE_ALWAYS
437	help
438	  Selects the sysfs defaults for Transparent Hugepage Support.
439
440	config TRANSPARENT_HUGEPAGE_ALWAYS
441		bool "always"
442	help
443	  Enabling Transparent Hugepage always, can increase the
444	  memory footprint of applications without a guaranteed
445	  benefit but it will work automatically for all applications.
446
447	config TRANSPARENT_HUGEPAGE_MADVISE
448		bool "madvise"
449	help
450	  Enabling Transparent Hugepage madvise, will only provide a
451	  performance improvement benefit to the applications using
452	  madvise(MADV_HUGEPAGE) but it won't risk to increase the
453	  memory footprint of applications without a guaranteed
454	  benefit.
455endchoice
456
457config ARCH_WANTS_THP_SWAP
458	def_bool n
459
460config THP_SWAP
461	def_bool y
462	depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP
463	help
464	  Swap transparent huge pages in one piece, without splitting.
465	  XXX: For now, swap cluster backing transparent huge page
466	  will be split after swapout.
467
468	  For selection by architectures with reasonable THP sizes.
469
470#
471# UP and nommu archs use km based percpu allocator
472#
473config NEED_PER_CPU_KM
474	depends on !SMP
475	bool
476	default y
477
478config CLEANCACHE
479	bool "Enable cleancache driver to cache clean pages if tmem is present"
480	help
481	  Cleancache can be thought of as a page-granularity victim cache
482	  for clean pages that the kernel's pageframe replacement algorithm
483	  (PFRA) would like to keep around, but can't since there isn't enough
484	  memory.  So when the PFRA "evicts" a page, it first attempts to use
485	  cleancache code to put the data contained in that page into
486	  "transcendent memory", memory that is not directly accessible or
487	  addressable by the kernel and is of unknown and possibly
488	  time-varying size.  And when a cleancache-enabled
489	  filesystem wishes to access a page in a file on disk, it first
490	  checks cleancache to see if it already contains it; if it does,
491	  the page is copied into the kernel and a disk access is avoided.
492	  When a transcendent memory driver is available (such as zcache or
493	  Xen transcendent memory), a significant I/O reduction
494	  may be achieved.  When none is available, all cleancache calls
495	  are reduced to a single pointer-compare-against-NULL resulting
496	  in a negligible performance hit.
497
498	  If unsure, say Y to enable cleancache
499
500config FRONTSWAP
501	bool "Enable frontswap to cache swap pages if tmem is present"
502	depends on SWAP
503	help
504	  Frontswap is so named because it can be thought of as the opposite
505	  of a "backing" store for a swap device.  The data is stored into
506	  "transcendent memory", memory that is not directly accessible or
507	  addressable by the kernel and is of unknown and possibly
508	  time-varying size.  When space in transcendent memory is available,
509	  a significant swap I/O reduction may be achieved.  When none is
510	  available, all frontswap calls are reduced to a single pointer-
511	  compare-against-NULL resulting in a negligible performance hit
512	  and swap data is stored as normal on the matching swap device.
513
514	  If unsure, say Y to enable frontswap.
515
516config CMA
517	bool "Contiguous Memory Allocator"
518	depends on MMU
519	select MIGRATION
520	select MEMORY_ISOLATION
521	help
522	  This enables the Contiguous Memory Allocator which allows other
523	  subsystems to allocate big physically-contiguous blocks of memory.
524	  CMA reserves a region of memory and allows only movable pages to
525	  be allocated from it. This way, the kernel can use the memory for
526	  pagecache and when a subsystem requests for contiguous area, the
527	  allocated pages are migrated away to serve the contiguous request.
528
529	  If unsure, say "n".
530
531config CMA_DEBUG
532	bool "CMA debug messages (DEVELOPMENT)"
533	depends on DEBUG_KERNEL && CMA
534	help
535	  Turns on debug messages in CMA.  This produces KERN_DEBUG
536	  messages for every CMA call as well as various messages while
537	  processing calls such as dma_alloc_from_contiguous().
538	  This option does not affect warning and error messages.
539
540config CMA_DEBUGFS
541	bool "CMA debugfs interface"
542	depends on CMA && DEBUG_FS
543	help
544	  Turns on the DebugFS interface for CMA.
545
546config CMA_AREAS
547	int "Maximum count of the CMA areas"
548	depends on CMA
549	default 19 if NUMA
550	default 7
551	help
552	  CMA allows to create CMA areas for particular purpose, mainly,
553	  used as device private area. This parameter sets the maximum
554	  number of CMA area in the system.
555
556	  If unsure, leave the default value "7" in UMA and "19" in NUMA.
557
558config CMA_REUSE
559	bool "CMA reuse feature"
560	depends on CMA
561	help
562	  If enabled, it will add MIGRATE_CMA to pcp lists and movable
563	  allocations with __GFP_CMA flag will use cma areas prior to
564	  movable areas.
565
566	  It improves the utilization ratio of cma areas.
567
568config MEM_SOFT_DIRTY
569	bool "Track memory changes"
570	depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS
571	select PROC_PAGE_MONITOR
572	help
573	  This option enables memory changes tracking by introducing a
574	  soft-dirty bit on pte-s. This bit it set when someone writes
575	  into a page just as regular dirty bit, but unlike the latter
576	  it can be cleared by hands.
577
578	  See Documentation/admin-guide/mm/soft-dirty.rst for more details.
579
580config ZSWAP
581	bool "Compressed cache for swap pages (EXPERIMENTAL)"
582	depends on FRONTSWAP && CRYPTO=y
583	select ZPOOL
584	help
585	  A lightweight compressed cache for swap pages.  It takes
586	  pages that are in the process of being swapped out and attempts to
587	  compress them into a dynamically allocated RAM-based memory pool.
588	  This can result in a significant I/O reduction on swap device and,
589	  in the case where decompressing from RAM is faster that swap device
590	  reads, can also improve workload performance.
591
592	  This is marked experimental because it is a new feature (as of
593	  v3.11) that interacts heavily with memory reclaim.  While these
594	  interactions don't cause any known issues on simple memory setups,
595	  they have not be fully explored on the large set of potential
596	  configurations and workloads that exist.
597
598choice
599	prompt "Compressed cache for swap pages default compressor"
600	depends on ZSWAP
601	default ZSWAP_COMPRESSOR_DEFAULT_LZO
602	help
603	  Selects the default compression algorithm for the compressed cache
604	  for swap pages.
605
606	  For an overview what kind of performance can be expected from
607	  a particular compression algorithm please refer to the benchmarks
608	  available at the following LWN page:
609	  https://lwn.net/Articles/751795/
610
611	  If in doubt, select 'LZO'.
612
613	  The selection made here can be overridden by using the kernel
614	  command line 'zswap.compressor=' option.
615
616config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE
617	bool "Deflate"
618	select CRYPTO_DEFLATE
619	help
620	  Use the Deflate algorithm as the default compression algorithm.
621
622config ZSWAP_COMPRESSOR_DEFAULT_LZO
623	bool "LZO"
624	select CRYPTO_LZO
625	help
626	  Use the LZO algorithm as the default compression algorithm.
627
628config ZSWAP_COMPRESSOR_DEFAULT_842
629	bool "842"
630	select CRYPTO_842
631	help
632	  Use the 842 algorithm as the default compression algorithm.
633
634config ZSWAP_COMPRESSOR_DEFAULT_LZ4
635	bool "LZ4"
636	select CRYPTO_LZ4
637	help
638	  Use the LZ4 algorithm as the default compression algorithm.
639
640config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC
641	bool "LZ4HC"
642	select CRYPTO_LZ4HC
643	help
644	  Use the LZ4HC algorithm as the default compression algorithm.
645
646config ZSWAP_COMPRESSOR_DEFAULT_ZSTD
647	bool "zstd"
648	select CRYPTO_ZSTD
649	help
650	  Use the zstd algorithm as the default compression algorithm.
651endchoice
652
653config ZSWAP_COMPRESSOR_DEFAULT
654       string
655       depends on ZSWAP
656       default "deflate" if ZSWAP_COMPRESSOR_DEFAULT_DEFLATE
657       default "lzo" if ZSWAP_COMPRESSOR_DEFAULT_LZO
658       default "842" if ZSWAP_COMPRESSOR_DEFAULT_842
659       default "lz4" if ZSWAP_COMPRESSOR_DEFAULT_LZ4
660       default "lz4hc" if ZSWAP_COMPRESSOR_DEFAULT_LZ4HC
661       default "zstd" if ZSWAP_COMPRESSOR_DEFAULT_ZSTD
662       default ""
663
664choice
665	prompt "Compressed cache for swap pages default allocator"
666	depends on ZSWAP
667	default ZSWAP_ZPOOL_DEFAULT_ZBUD
668	help
669	  Selects the default allocator for the compressed cache for
670	  swap pages.
671	  The default is 'zbud' for compatibility, however please do
672	  read the description of each of the allocators below before
673	  making a right choice.
674
675	  The selection made here can be overridden by using the kernel
676	  command line 'zswap.zpool=' option.
677
678config ZSWAP_ZPOOL_DEFAULT_ZBUD
679	bool "zbud"
680	select ZBUD
681	help
682	  Use the zbud allocator as the default allocator.
683
684config ZSWAP_ZPOOL_DEFAULT_Z3FOLD
685	bool "z3fold"
686	select Z3FOLD
687	help
688	  Use the z3fold allocator as the default allocator.
689
690config ZSWAP_ZPOOL_DEFAULT_ZSMALLOC
691	bool "zsmalloc"
692	select ZSMALLOC
693	help
694	  Use the zsmalloc allocator as the default allocator.
695endchoice
696
697config ZSWAP_ZPOOL_DEFAULT
698       string
699       depends on ZSWAP
700       default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD
701       default "z3fold" if ZSWAP_ZPOOL_DEFAULT_Z3FOLD
702       default "zsmalloc" if ZSWAP_ZPOOL_DEFAULT_ZSMALLOC
703       default ""
704
705config ZSWAP_DEFAULT_ON
706	bool "Enable the compressed cache for swap pages by default"
707	depends on ZSWAP
708	help
709	  If selected, the compressed cache for swap pages will be enabled
710	  at boot, otherwise it will be disabled.
711
712	  The selection made here can be overridden by using the kernel
713	  command line 'zswap.enabled=' option.
714
715config ZPOOL
716	tristate "Common API for compressed memory storage"
717	help
718	  Compressed memory storage API.  This allows using either zbud or
719	  zsmalloc.
720
721config ZBUD
722	tristate "Low (Up to 2x) density storage for compressed pages"
723	help
724	  A special purpose allocator for storing compressed pages.
725	  It is designed to store up to two compressed pages per physical
726	  page.  While this design limits storage density, it has simple and
727	  deterministic reclaim properties that make it preferable to a higher
728	  density approach when reclaim will be used.
729
730config Z3FOLD
731	tristate "Up to 3x density storage for compressed pages"
732	depends on ZPOOL
733	help
734	  A special purpose allocator for storing compressed pages.
735	  It is designed to store up to three compressed pages per physical
736	  page. It is a ZBUD derivative so the simplicity and determinism are
737	  still there.
738
739config ZSMALLOC
740	tristate "Memory allocator for compressed pages"
741	depends on MMU
742	help
743	  zsmalloc is a slab-based memory allocator designed to store
744	  compressed RAM pages.  zsmalloc uses virtual memory mapping
745	  in order to reduce fragmentation.  However, this results in a
746	  non-standard allocator interface where a handle, not a pointer, is
747	  returned by an alloc().  This handle must be mapped in order to
748	  access the allocated space.
749
750config ZSMALLOC_STAT
751	bool "Export zsmalloc statistics"
752	depends on ZSMALLOC
753	select DEBUG_FS
754	help
755	  This option enables code in the zsmalloc to collect various
756	  statistics about whats happening in zsmalloc and exports that
757	  information to userspace via debugfs.
758	  If unsure, say N.
759
760config GENERIC_EARLY_IOREMAP
761	bool
762
763config MAX_STACK_SIZE_MB
764	int "Maximum user stack size for 32-bit processes (MB)"
765	default 80
766	range 8 2048
767	depends on STACK_GROWSUP && (!64BIT || COMPAT)
768	help
769	  This is the maximum stack size in Megabytes in the VM layout of 32-bit
770	  user processes when the stack grows upwards (currently only on parisc
771	  arch). The stack will be located at the highest memory address minus
772	  the given value, unless the RLIMIT_STACK hard limit is changed to a
773	  smaller value in which case that is used.
774
775	  A sane initial value is 80 MB.
776
777config DEFERRED_STRUCT_PAGE_INIT
778	bool "Defer initialisation of struct pages to kthreads"
779	depends on SPARSEMEM
780	depends on !NEED_PER_CPU_KM
781	depends on 64BIT
782	select PADATA
783	help
784	  Ordinarily all struct pages are initialised during early boot in a
785	  single thread. On very large machines this can take a considerable
786	  amount of time. If this option is set, large machines will bring up
787	  a subset of memmap at boot and then initialise the rest in parallel.
788	  This has a potential performance impact on tasks running early in the
789	  lifetime of the system until these kthreads finish the
790	  initialisation.
791
792config IDLE_PAGE_TRACKING
793	bool "Enable idle page tracking"
794	depends on SYSFS && MMU
795	select PAGE_EXTENSION if !64BIT
796	help
797	  This feature allows to estimate the amount of user pages that have
798	  not been touched during a given period of time. This information can
799	  be useful to tune memory cgroup limits and/or for job placement
800	  within a compute cluster.
801
802	  See Documentation/admin-guide/mm/idle_page_tracking.rst for
803	  more details.
804
805config ARCH_HAS_PTE_DEVMAP
806	bool
807
808config ZONE_DEVICE
809	bool "Device memory (pmem, HMM, etc...) hotplug support"
810	depends on MEMORY_HOTPLUG
811	depends on MEMORY_HOTREMOVE
812	depends on SPARSEMEM_VMEMMAP
813	depends on ARCH_HAS_PTE_DEVMAP
814	select XARRAY_MULTI
815
816	help
817	  Device memory hotplug support allows for establishing pmem,
818	  or other device driver discovered memory regions, in the
819	  memmap. This allows pfn_to_page() lookups of otherwise
820	  "device-physical" addresses which is needed for using a DAX
821	  mapping in an O_DIRECT operation, among other things.
822
823	  If FS_DAX is enabled, then say Y.
824
825config DEV_PAGEMAP_OPS
826	bool
827
828#
829# Helpers to mirror range of the CPU page tables of a process into device page
830# tables.
831#
832config HMM_MIRROR
833	bool
834	depends on MMU
835
836config DEVICE_PRIVATE
837	bool "Unaddressable device memory (GPU memory, ...)"
838	depends on ZONE_DEVICE
839	select DEV_PAGEMAP_OPS
840
841	help
842	  Allows creation of struct pages to represent unaddressable device
843	  memory; i.e., memory that is only accessible from the device (or
844	  group of devices). You likely also want to select HMM_MIRROR.
845
846config VMAP_PFN
847	bool
848
849config FRAME_VECTOR
850	bool
851
852config ARCH_USES_HIGH_VMA_FLAGS
853	bool
854config ARCH_HAS_PKEYS
855	bool
856
857config PERCPU_STATS
858	bool "Collect percpu memory statistics"
859	help
860	  This feature collects and exposes statistics via debugfs. The
861	  information includes global and per chunk statistics, which can
862	  be used to help understand percpu memory usage.
863
864config GUP_BENCHMARK
865	bool "Enable infrastructure for get_user_pages() and related calls benchmarking"
866	help
867	  Provides /sys/kernel/debug/gup_benchmark that helps with testing
868	  performance of get_user_pages() and related calls.
869
870	  See tools/testing/selftests/vm/gup_benchmark.c
871
872config GUP_GET_PTE_LOW_HIGH
873	bool
874
875config READ_ONLY_THP_FOR_FS
876	bool "Read-only THP for filesystems (EXPERIMENTAL)"
877	depends on TRANSPARENT_HUGEPAGE && SHMEM
878
879	help
880	  Allow khugepaged to put read-only file-backed pages in THP.
881
882	  This is marked experimental because it is a new feature. Write
883	  support of file THPs will be developed in the next few release
884	  cycles.
885
886config ARCH_HAS_PTE_SPECIAL
887	bool
888
889#
890# Some architectures require a special hugepage directory format that is
891# required to support multiple hugepage sizes. For example a4fe3ce76
892# "powerpc/mm: Allow more flexible layouts for hugepage pagetables"
893# introduced it on powerpc.  This allows for a more flexible hugepage
894# pagetable layouts.
895#
896config ARCH_HAS_HUGEPD
897	bool
898
899config MAPPING_DIRTY_HELPERS
900        bool
901
902config ANON_VMA_NAME
903	bool "Anonymous VMA name support"
904	depends on PROC_FS && ADVISE_SYSCALLS && MMU
905
906	help
907	  Allow naming anonymous virtual memory areas.
908
909	  This feature allows assigning names to virtual memory areas. Assigned
910	  names can be later retrieved from /proc/pid/maps and /proc/pid/smaps
911	  and help identifying individual anonymous memory areas.
912	  Assigning a name to anonymous virtual memory area might prevent that
913	  area from being merged with adjacent virtual memory areas due to the
914	  difference in their name.
915
916endmenu
917