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