projects/linux·blob master · refs

1516 lines · 47.0 KiB

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
12menuconfig SWAP
13 bool "Support for paging of anonymous memory (swap)"
14 depends on MMU && BLOCK && !ARCH_NO_SWAP
15 default y
16 help
17 This option allows you to choose whether you want to have support
18 for so called swap devices or swap files in your kernel that are
19 used to provide more virtual memory than the actual RAM present
20 in your computer. If unsure say Y.
21
22config ZSWAP
23 bool "Compressed cache for swap pages"
24 depends on SWAP
25 select CRYPTO
26 select ZSMALLOC
27 help
28 A lightweight compressed cache for swap pages. It takes
29 pages that are in the process of being swapped out and attempts to
30 compress them into a dynamically allocated RAM-based memory pool.
31 This can result in a significant I/O reduction on swap device and,
32 in the case where decompressing from RAM is faster than swap device
33 reads, can also improve workload performance.
34
35config ZSWAP_DEFAULT_ON
36 bool "Enable the compressed cache for swap pages by default"
37 depends on ZSWAP
38 help
39 If selected, the compressed cache for swap pages will be enabled
40 at boot, otherwise it will be disabled.
41
42 The selection made here can be overridden by using the kernel
43 command line 'zswap.enabled=' option.
44
45config ZSWAP_SHRINKER_DEFAULT_ON
46 bool "Shrink the zswap pool on memory pressure"
47 depends on ZSWAP
48 default n
49 help
50 If selected, the zswap shrinker will be enabled, and the pages
51 stored in the zswap pool will become available for reclaim (i.e
52 written back to the backing swap device) on memory pressure.
53
54 This means that zswap writeback could happen even if the pool is
55 not yet full, or the cgroup zswap limit has not been reached,
56 reducing the chance that cold pages will reside in the zswap pool
57 and consume memory indefinitely.
58
59choice
60 prompt "Default compressor"
61 depends on ZSWAP
62 default ZSWAP_COMPRESSOR_DEFAULT_LZO
63 help
64 Selects the default compression algorithm for the compressed cache
65 for swap pages.
66
67 For an overview what kind of performance can be expected from
68 a particular compression algorithm please refer to the benchmarks
69 available at the following LWN page:
70 https://lwn.net/Articles/751795/
71
72 If in doubt, select 'LZO'.
73
74 The selection made here can be overridden by using the kernel
75 command line 'zswap.compressor=' option.
76
77config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE
78 bool "Deflate"
79 select CRYPTO_DEFLATE
80 help
81 Use the Deflate algorithm as the default compression algorithm.
82
83config ZSWAP_COMPRESSOR_DEFAULT_LZO
84 bool "LZO"
85 select CRYPTO_LZO
86 help
87 Use the LZO algorithm as the default compression algorithm.
88
89config ZSWAP_COMPRESSOR_DEFAULT_842
90 bool "842"
91 select CRYPTO_842
92 help
93 Use the 842 algorithm as the default compression algorithm.
94
95config ZSWAP_COMPRESSOR_DEFAULT_LZ4
96 bool "LZ4"
97 select CRYPTO_LZ4
98 help
99 Use the LZ4 algorithm as the default compression algorithm.
100
101config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC
102 bool "LZ4HC"
103 select CRYPTO_LZ4HC
104 help
105 Use the LZ4HC algorithm as the default compression algorithm.
106
107config ZSWAP_COMPRESSOR_DEFAULT_ZSTD
108 bool "zstd"
109 select CRYPTO_ZSTD
110 help
111 Use the zstd algorithm as the default compression algorithm.
112endchoice
113
114config ZSWAP_COMPRESSOR_DEFAULT
115 string
116 depends on ZSWAP
117 default "deflate" if ZSWAP_COMPRESSOR_DEFAULT_DEFLATE
118 default "lzo" if ZSWAP_COMPRESSOR_DEFAULT_LZO
119 default "842" if ZSWAP_COMPRESSOR_DEFAULT_842
120 default "lz4" if ZSWAP_COMPRESSOR_DEFAULT_LZ4
121 default "lz4hc" if ZSWAP_COMPRESSOR_DEFAULT_LZ4HC
122 default "zstd" if ZSWAP_COMPRESSOR_DEFAULT_ZSTD
123 default ""
124
125config ZSMALLOC
126 tristate
127
128menu "Zsmalloc allocator options"
129 depends on ZSMALLOC
130
131comment "Zsmalloc is a common backend allocator for zswap & zram"
132
133config ZSMALLOC_STAT
134 bool "Export zsmalloc statistics"
135 select DEBUG_FS
136 help
137 This option enables code in the zsmalloc to collect various
138 statistics about what's happening in zsmalloc and exports that
139 information to userspace via debugfs.
140 If unsure, say N.
141
142config ZSMALLOC_CHAIN_SIZE
143 int "Maximum number of physical pages per-zspage"
144 default 8
145 range 4 16
146 help
147 This option sets the upper limit on the number of physical pages
148 that a zmalloc page (zspage) can consist of. The optimal zspage
149 chain size is calculated for each size class during the
150 initialization of the pool.
151
152 Changing this option can alter the characteristics of size classes,
153 such as the number of pages per zspage and the number of objects
154 per zspage. This can also result in different configurations of
155 the pool, as zsmalloc merges size classes with similar
156 characteristics.
157
158 For more information, see zsmalloc documentation.
159
160endmenu
161
162menu "Slab allocator options"
163
164config SLUB
165 def_bool y
166 select IRQ_WORK
167
168config KVFREE_RCU_BATCHED
169 def_bool y
170 depends on !SLUB_TINY && !TINY_RCU
171 depends on !RCU_STRICT_GRACE_PERIOD
172
173config SLUB_TINY
174 bool "Configure for minimal memory footprint"
175 depends on EXPERT && !COMPILE_TEST
176 select SLAB_MERGE_DEFAULT
177 help
178 Configures the slab allocator in a way to achieve minimal memory
179 footprint, sacrificing scalability, debugging and other features.
180 This is intended only for the smallest system that had used the
181 SLOB allocator and is not recommended for systems with more than
182 16MB RAM.
183
184 If unsure, say N.
185
186config SLAB_MERGE_DEFAULT
187 bool "Allow slab caches to be merged"
188 default y
189 help
190 For reduced kernel memory fragmentation, slab caches can be
191 merged when they share the same size and other characteristics.
192 This carries a risk of kernel heap overflows being able to
193 overwrite objects from merged caches (and more easily control
194 cache layout), which makes such heap attacks easier to exploit
195 by attackers. By keeping caches unmerged, these kinds of exploits
196 can usually only damage objects in the same cache. To disable
197 merging at runtime, "slab_nomerge" can be passed on the kernel
198 command line.
199
200config SLAB_FREELIST_RANDOM
201 bool "Randomize slab freelist"
202 depends on !SLUB_TINY
203 help
204 Randomizes the freelist order used on creating new pages. This
205 security feature reduces the predictability of the kernel slab
206 allocator against heap overflows.
207
208config SLAB_FREELIST_HARDENED
209 bool "Harden slab freelist metadata"
210 depends on !SLUB_TINY
211 help
212 Many kernel heap attacks try to target slab cache metadata and
213 other infrastructure. This options makes minor performance
214 sacrifices to harden the kernel slab allocator against common
215 freelist exploit methods.
216
217config SLAB_BUCKETS
218 bool "Support allocation from separate kmalloc buckets"
219 depends on !SLUB_TINY
220 default SLAB_FREELIST_HARDENED
221 help
222 Kernel heap attacks frequently depend on being able to create
223 specifically-sized allocations with user-controlled contents
224 that will be allocated into the same kmalloc bucket as a
225 target object. To avoid sharing these allocation buckets,
226 provide an explicitly separated set of buckets to be used for
227 user-controlled allocations. This may very slightly increase
228 memory fragmentation, though in practice it's only a handful
229 of extra pages since the bulk of user-controlled allocations
230 are relatively long-lived.
231
232 If unsure, say Y.
233
234config SLUB_STATS
235 default n
236 bool "Enable performance statistics"
237 depends on SYSFS && !SLUB_TINY
238 help
239 The statistics are useful to debug slab allocation behavior in
240 order find ways to optimize the allocator. This should never be
241 enabled for production use since keeping statistics slows down
242 the allocator by a few percentage points. The slabinfo command
243 supports the determination of the most active slabs to figure
244 out which slabs are relevant to a particular load.
245 Try running: slabinfo -DA
246
247config KMALLOC_PARTITION_CACHES
248 depends on !SLUB_TINY
249 bool "Partitioned slab caches for normal kmalloc"
250 default RANDOM_KMALLOC_CACHES
251 help
252 A hardening feature that creates multiple isolated copies of slab
253 caches for normal kmalloc allocations. This makes it more difficult
254 to exploit memory-safety vulnerabilities by attacking vulnerable
255 co-located memory objects. Several modes are provided.
256
257 Currently the number of copies is set to 16, a reasonably large value
258 that effectively diverges the memory objects allocated for different
259 subsystems or modules into different caches, at the expense of a
260 limited degree of memory and CPU overhead that relates to hardware
261 and system workload.
262
263choice
264 prompt "Partitioned slab cache mode"
265 depends on KMALLOC_PARTITION_CACHES
266 default KMALLOC_PARTITION_TYPED if CC_HAS_ALLOC_TOKEN
267 default KMALLOC_PARTITION_RANDOM
268 help
269 Selects the slab cache partitioning mode.
270
271config KMALLOC_PARTITION_RANDOM
272 bool "Randomize slab caches for normal kmalloc"
273 help
274 Randomly pick a slab cache based on code address and a per-boot
275 random seed.
276
277 This makes it harder for attackers to predict object co-location.
278 The placement is random: while attackers don't know which kmalloc
279 cache an object will be allocated from, they might circumvent
280 the randomization by retrying attacks across multiple machines until
281 the target objects are co-located.
282
283config KMALLOC_PARTITION_TYPED
284 bool "Type based slab cache selection for normal kmalloc"
285 depends on CC_HAS_ALLOC_TOKEN
286 help
287 Rely on Clang's allocation tokens to choose a slab cache, where token
288 IDs are derived from the allocated type.
289
290 Unlike KMALLOC_PARTITION_RANDOM, cache assignment is deterministic based
291 on type, which guarantees that objects of certain types are not
292 placed in the same cache. This effectively mitigates certain classes
293 of exploits that probabilistic defenses like KMALLOC_PARTITION_RANDOM
294 only make harder but not impossible. However, this also means the
295 cache assignment is predictable.
296
297 Clang's default token ID calculation returns a bounded hash with
298 disjoint ranges for pointer-containing and pointerless objects: when
299 used as the slab cache index, this prevents buffer overflows on
300 primitive buffers from directly corrupting pointer-containing
301 objects.
302
303 The current effectiveness of Clang's type inference can be judged by
304 -Rpass=alloc-token, which provides diagnostics where (after dead-code
305 elimination) type inference failed.
306
307 Requires Clang 22 or later.
308
309endchoice
310
311config RANDOM_KMALLOC_CACHES
312 bool
313 transitional
314 help
315 Transitional config for migration to KMALLOC_PARTITION_CACHES.
316
317endmenu # Slab allocator options
318
319config SHUFFLE_PAGE_ALLOCATOR
320 bool "Page allocator randomization"
321 default SLAB_FREELIST_RANDOM && ACPI_NUMA
322 help
323 Randomization of the page allocator improves the average
324 utilization of a direct-mapped memory-side-cache. See section
325 5.2.27 Heterogeneous Memory Attribute Table (HMAT) in the ACPI
326 6.2a specification for an example of how a platform advertises
327 the presence of a memory-side-cache. There are also incidental
328 security benefits as it reduces the predictability of page
329 allocations to compliment SLAB_FREELIST_RANDOM, but the
330 default granularity of shuffling on the MAX_PAGE_ORDER i.e, 10th
331 order of pages is selected based on cache utilization benefits
332 on x86.
333
334 While the randomization improves cache utilization it may
335 negatively impact workloads on platforms without a cache. For
336 this reason, by default, the randomization is not enabled even
337 if SHUFFLE_PAGE_ALLOCATOR=y. The randomization may be force enabled
338 with the 'page_alloc.shuffle' kernel command line parameter.
339
340 Say Y if unsure.
341
342config COMPAT_BRK
343 bool "Disable heap randomization"
344 default y
345 help
346 Randomizing heap placement makes heap exploits harder, but it
347 also breaks ancient binaries (including anything libc5 based).
348 This option changes the bootup default to heap randomization
349 disabled, and can be overridden at runtime by setting
350 /proc/sys/kernel/randomize_va_space to 2.
351
352 On non-ancient distros (post-2000 ones) N is usually a safe choice.
353
354config MMAP_ALLOW_UNINITIALIZED
355 bool "Allow mmapped anonymous memory to be uninitialized"
356 depends on EXPERT && !MMU
357 default n
358 help
359 Normally, and according to the Linux spec, anonymous memory obtained
360 from mmap() has its contents cleared before it is passed to
361 userspace. Enabling this config option allows you to request that
362 mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
363 providing a huge performance boost. If this option is not enabled,
364 then the flag will be ignored.
365
366 This is taken advantage of by uClibc's malloc(), and also by
367 ELF-FDPIC binfmt's brk and stack allocator.
368
369 Because of the obvious security issues, this option should only be
370 enabled on embedded devices where you control what is run in
371 userspace. Since that isn't generally a problem on no-MMU systems,
372 it is normally safe to say Y here.
373
374 See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
375
376config SELECT_MEMORY_MODEL
377 def_bool y
378 depends on ARCH_SELECT_MEMORY_MODEL
379
380choice
381 prompt "Memory model"
382 depends on SELECT_MEMORY_MODEL
383 default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT
384 default FLATMEM_MANUAL
385 help
386 This option allows you to change some of the ways that
387 Linux manages its memory internally. Most users will
388 only have one option here selected by the architecture
389 configuration. This is normal.
390
391config FLATMEM_MANUAL
392 bool "Flat Memory"
393 depends on !NUMA
394 depends on !ARCH_SPARSEMEM_ENABLE || ARCH_FLATMEM_ENABLE
395 help
396 This option is best suited for non-NUMA systems with
397 flat address space. The FLATMEM is the most efficient
398 system in terms of performance and resource consumption
399 and it is the best option for smaller systems.
400
401 For systems that have holes in their physical address
402 spaces and for features like NUMA and memory hotplug,
403 choose "Sparse Memory".
404
405 If unsure, choose this option (Flat Memory) over any other.
406
407config SPARSEMEM_MANUAL
408 bool "Sparse Memory"
409 depends on ARCH_SPARSEMEM_ENABLE
410 help
411 This will be the only option for some systems, including
412 memory hot-plug systems. This is normal.
413
414 This option provides efficient support for systems with
415 holes is their physical address space and allows memory
416 hot-plug and hot-remove.
417
418 If unsure, choose "Flat Memory" over this option.
419
420endchoice
421
422config SPARSEMEM
423 def_bool y
424 depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL
425
426config FLATMEM
427 def_bool y
428 depends on !NUMA
429 depends on !SPARSEMEM || FLATMEM_MANUAL
430
431#
432# SPARSEMEM_EXTREME (which is the default) does some bootmem
433# allocations when sparse_init() is called. If this cannot
434# be done on your architecture, select this option. However,
435# statically allocating the mem_section[] array can potentially
436# consume vast quantities of .bss, so be careful.
437#
438# This option will also potentially produce smaller runtime code
439# with gcc 3.4 and later.
440#
441config SPARSEMEM_STATIC
442 bool
443
444#
445# Architecture platforms which require a two level mem_section in SPARSEMEM
446# must select this option. This is usually for architecture platforms with
447# an extremely sparse physical address space.
448#
449config SPARSEMEM_EXTREME
450 def_bool y
451 depends on SPARSEMEM && !SPARSEMEM_STATIC
452
453config SPARSEMEM_VMEMMAP_ENABLE
454 bool
455
456config SPARSEMEM_VMEMMAP
457 def_bool y
458 depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE
459 help
460 SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise
461 pfn_to_page and page_to_pfn operations. This is the most
462 efficient option when sufficient kernel resources are available.
463
464config SPARSEMEM_VMEMMAP_PREINIT
465 bool
466#
467# Select this config option from the architecture Kconfig, if it is preferred
468# to enable the feature of HugeTLB/dev_dax vmemmap optimization.
469#
470config ARCH_WANT_OPTIMIZE_DAX_VMEMMAP
471 bool
472
473config ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
474 bool
475
476config ARCH_WANT_HUGETLB_VMEMMAP_PREINIT
477 bool
478
479config HAVE_MEMBLOCK_PHYS_MAP
480 bool
481
482config HAVE_GUP_FAST
483 depends on MMU
484 bool
485
486# Enable memblock support for scratch memory which is needed for kexec handover
487config MEMBLOCK_KHO_SCRATCH
488 bool
489
490# Don't discard allocated memory used to track "memory" and "reserved" memblocks
491# after early boot, so it can still be used to test for validity of memory.
492# Also, memblocks are updated with memory hot(un)plug.
493config ARCH_KEEP_MEMBLOCK
494 bool
495
496# Keep arch NUMA mapping infrastructure post-init.
497config NUMA_KEEP_MEMINFO
498 bool
499
500config MEMORY_ISOLATION
501 bool
502
503# IORESOURCE_SYSTEM_RAM regions in the kernel resource tree that are marked
504# IORESOURCE_EXCLUSIVE cannot be mapped to user space, for example, via
505# /dev/mem.
506config EXCLUSIVE_SYSTEM_RAM
507 def_bool y
508 depends on !DEVMEM || STRICT_DEVMEM
509
510config ARCH_ENABLE_MEMORY_HOTPLUG
511 bool
512
513# eventually, we can have this option just 'select SPARSEMEM'
514menuconfig MEMORY_HOTPLUG
515 bool "Memory hotplug"
516 select MEMORY_ISOLATION
517 depends on SPARSEMEM_VMEMMAP
518 depends on ARCH_ENABLE_MEMORY_HOTPLUG
519 depends on 64BIT
520 select NUMA_KEEP_MEMINFO if NUMA
521
522if MEMORY_HOTPLUG
523
524choice
525 prompt "Memory Hotplug Default Online Type"
526 default MHP_DEFAULT_ONLINE_TYPE_OFFLINE
527 help
528 Default memory type for hotplugged memory.
529
530 This option sets the default policy setting for memory hotplug
531 onlining policy (/sys/devices/system/memory/auto_online_blocks) which
532 determines what happens to newly added memory regions. Policy setting
533 can always be changed at runtime.
534
535 The default is 'offline'.
536
537 Select offline to defer onlining to drivers and user policy.
538 Select auto to let the kernel choose what zones to utilize.
539 Select online_kernel to generally allow kernel usage of this memory.
540 Select online_movable to generally disallow kernel usage of this memory.
541
542 Example kernel usage would be page structs and page tables.
543
544 See Documentation/admin-guide/mm/memory-hotplug.rst for more information.
545
546config MHP_DEFAULT_ONLINE_TYPE_OFFLINE
547 bool "offline"
548 help
549 Hotplugged memory will not be onlined by default.
550 Choose this for systems with drivers and user policy that
551 handle onlining of hotplug memory policy.
552
553config MHP_DEFAULT_ONLINE_TYPE_ONLINE_AUTO
554 bool "auto"
555 help
556 Select this if you want the kernel to automatically online
557 hotplugged memory into the zone it thinks is reasonable.
558 This memory may be utilized for kernel data.
559
560config MHP_DEFAULT_ONLINE_TYPE_ONLINE_KERNEL
561 bool "kernel"
562 help
563 Select this if you want the kernel to automatically online
564 hotplugged memory into a zone capable of being used for kernel
565 data. This typically means ZONE_NORMAL.
566
567config MHP_DEFAULT_ONLINE_TYPE_ONLINE_MOVABLE
568 bool "movable"
569 help
570 Select this if you want the kernel to automatically online
571 hotplug memory into ZONE_MOVABLE. This memory will generally
572 not be utilized for kernel data.
573
574 This should only be used when the admin knows sufficient
575 ZONE_NORMAL memory is available to describe hotplug memory,
576 otherwise hotplug memory may fail to online. For example,
577 sufficient kernel-capable memory (ZONE_NORMAL) must be
578 available to allocate page structs to describe ZONE_MOVABLE.
579
580endchoice
581
582config MEMORY_HOTREMOVE
583 bool "Allow for memory hot remove"
584 select MIGRATION
585
586config MHP_MEMMAP_ON_MEMORY
587 def_bool y
588 depends on ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
589
590endif # MEMORY_HOTPLUG
591
592config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
593 bool
594
595# Heavily threaded applications may benefit from splitting the mm-wide
596# page_table_lock, so that faults on different parts of the user address
597# space can be handled with less contention: split it at this NR_CPUS.
598# Default to 4 for wider testing, though 8 might be more appropriate.
599# ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
600# PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
601# SPARC32 allocates multiple pte tables within a single page, and therefore
602# a per-page lock leads to problems when multiple tables need to be locked
603# at the same time (e.g. copy_page_range()).
604# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page.
605#
606config SPLIT_PTE_PTLOCKS
607 def_bool y
608 depends on MMU
609 depends on SMP
610 depends on NR_CPUS >= 4
611 depends on !ARM || CPU_CACHE_VIPT
612 depends on !PARISC || PA20
613 depends on !SPARC32
614 depends on !UML
615
616config ARCH_ENABLE_SPLIT_PMD_PTLOCK
617 bool
618
619config SPLIT_PMD_PTLOCKS
620 def_bool y
621 depends on SPLIT_PTE_PTLOCKS && ARCH_ENABLE_SPLIT_PMD_PTLOCK
622
623#
624# support for memory balloon
625config BALLOON
626 bool
627
628#
629# support for memory balloon page migration
630config BALLOON_MIGRATION
631 bool "Allow for balloon memory migration"
632 default y
633 depends on MIGRATION && BALLOON
634 help
635 Allow for migration of pages inflated in a memory balloon such that
636 they can be allocated from memory areas only available for movable
637 allocations (e.g., ZONE_MOVABLE, CMA) and such that they can be
638 migrated for memory defragmentation purposes by memory compaction.
639
640#
641# support for memory compaction
642config COMPACTION
643 bool "Allow for memory compaction"
644 default y
645 select MIGRATION
646 depends on MMU
647 help
648 Compaction is the only memory management component to form
649 high order (larger physically contiguous) memory blocks
650 reliably. The page allocator relies on compaction heavily and
651 the lack of the feature can lead to unexpected OOM killer
652 invocations for high order memory requests. You shouldn't
653 disable this option unless there really is a strong reason for
654 it and then we would be really interested to hear about that at
655 [email protected].
656
657config COMPACT_UNEVICTABLE_DEFAULT
658 int
659 depends on COMPACTION
660 default 0 if PREEMPT_RT
661 default 1
662
663#
664# support for free page reporting
665config PAGE_REPORTING
666 bool "Free page reporting"
667 help
668 Free page reporting allows for the incremental acquisition of
669 free pages from the buddy allocator for the purpose of reporting
670 those pages to another entity, such as a hypervisor, so that the
671 memory can be freed within the host for other uses.
672
673config NUMA_MIGRATION
674 bool "NUMA page migration"
675 default y
676 depends on NUMA && MMU
677 select MIGRATION
678 help
679 Support the migration of pages to other NUMA nodes, available to
680 user space through interfaces like migrate_pages(), move_pages(),
681 and mbind(). Selecting this option also enables support for page
682 demotion for memory tiering.
683
684config MIGRATION
685 bool
686 depends on MMU
687
688config DEVICE_MIGRATION
689 def_bool MIGRATION && ZONE_DEVICE
690
691config ARCH_ENABLE_HUGEPAGE_MIGRATION
692 bool
693
694config ARCH_HAS_PMD_SOFTLEAVES
695 bool
696
697config HUGETLB_PAGE_SIZE_VARIABLE
698 def_bool n
699 help
700 Allows the pageblock_order value to be dynamic instead of just standard
701 HUGETLB_PAGE_ORDER when there are multiple HugeTLB page sizes available
702 on a platform.
703
704 Note that the pageblock_order cannot exceed MAX_PAGE_ORDER and will be
705 clamped down to MAX_PAGE_ORDER.
706
707config CONTIG_ALLOC
708 def_bool (MEMORY_ISOLATION && COMPACTION) || CMA
709
710config PCP_BATCH_SCALE_MAX
711 int "Maximum scale factor of PCP (Per-CPU pageset) batch allocate/free"
712 default 5
713 range 0 6
714 help
715 In page allocator, PCP (Per-CPU pageset) is refilled and drained in
716 batches. The batch number is scaled automatically to improve page
717 allocation/free throughput. But too large scale factor may hurt
718 latency. This option sets the upper limit of scale factor to limit
719 the maximum latency.
720
721config PHYS_ADDR_T_64BIT
722 def_bool 64BIT
723
724config MMU_NOTIFIER
725 bool
726 select INTERVAL_TREE
727
728config KSM
729 bool "Enable KSM for page merging"
730 depends on MMU
731 select XXHASH
732 help
733 Enable Kernel Samepage Merging: KSM periodically scans those areas
734 of an application's address space that an app has advised may be
735 mergeable. When it finds pages of identical content, it replaces
736 the many instances by a single page with that content, so
737 saving memory until one or another app needs to modify the content.
738 Recommended for use with KVM, or with other duplicative applications.
739 See Documentation/mm/ksm.rst for more information: KSM is inactive
740 until a program has madvised that an area is MADV_MERGEABLE, and
741 root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set).
742
743config DEFAULT_MMAP_MIN_ADDR
744 int "Low address space to protect from user allocation"
745 depends on MMU
746 default 4096
747 help
748 This is the portion of low virtual memory which should be protected
749 from userspace allocation. Keeping a user from writing to low pages
750 can help reduce the impact of kernel NULL pointer bugs.
751
752 For most arm64, ppc64 and x86 users with lots of address space
753 a value of 65536 is reasonable and should cause no problems.
754 On arm and other archs it should not be higher than 32768.
755 Programs which use vm86 functionality or have some need to map
756 this low address space will need CAP_SYS_RAWIO or disable this
757 protection by setting the value to 0.
758
759 This value can be changed after boot using the
760 /proc/sys/vm/mmap_min_addr tunable.
761
762config ARCH_SUPPORTS_MEMORY_FAILURE
763 bool
764
765config MEMORY_FAILURE
766 depends on MMU
767 depends on ARCH_SUPPORTS_MEMORY_FAILURE
768 bool "Enable recovery from hardware memory errors"
769 select INTERVAL_TREE
770 select MIGRATION
771 help
772 Enables code to recover from some memory failures on systems
773 with MCA recovery. This allows a system to continue running
774 even when some of its memory has uncorrected errors. This requires
775 special hardware support and typically ECC memory.
776
777config HWPOISON_INJECT
778 tristate "HWPoison pages injector"
779 depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
780 select PROC_PAGE_MONITOR
781
782config NOMMU_INITIAL_TRIM_EXCESS
783 int "Turn on mmap() excess space trimming before booting"
784 depends on !MMU
785 default 1
786 help
787 The NOMMU mmap() frequently needs to allocate large contiguous chunks
788 of memory on which to store mappings, but it can only ask the system
789 allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently
790 more than it requires. To deal with this, mmap() is able to trim off
791 the excess and return it to the allocator.
792
793 If trimming is enabled, the excess is trimmed off and returned to the
794 system allocator, which can cause extra fragmentation, particularly
795 if there are a lot of transient processes.
796
797 If trimming is disabled, the excess is kept, but not used, which for
798 long-term mappings means that the space is wasted.
799
800 Trimming can be dynamically controlled through a sysctl option
801 (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of
802 excess pages there must be before trimming should occur, or zero if
803 no trimming is to occur.
804
805 This option specifies the initial value of this option. The default
806 of 1 says that all excess pages should be trimmed.
807
808 See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
809
810config ARCH_WANT_GENERAL_HUGETLB
811 bool
812
813config ARCH_WANTS_THP_SWAP
814 def_bool n
815
816config PERSISTENT_HUGE_ZERO_FOLIO
817 bool "Allocate a PMD sized folio for zeroing"
818 depends on TRANSPARENT_HUGEPAGE
819 help
820 Enable this option to reduce the runtime refcounting overhead
821 of the huge zero folio and expand the places in the kernel
822 that can use huge zero folios. For instance, block I/O benefits
823 from access to large folios for zeroing memory.
824
825 With this option enabled, the huge zero folio is allocated
826 once and never freed. One full huge page's worth of memory shall
827 be used.
828
829 Say Y if your system has lots of memory. Say N if you are
830 memory constrained.
831
832config MM_ID
833 def_bool n
834
835menuconfig TRANSPARENT_HUGEPAGE
836 bool "Transparent Hugepage Support"
837 depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE && !PREEMPT_RT
838 select COMPACTION
839 select XARRAY_MULTI
840 select MM_ID
841 help
842 Transparent Hugepages allows the kernel to use huge pages and
843 huge tlb transparently to the applications whenever possible.
844 This feature can improve computing performance to certain
845 applications by speeding up page faults during memory
846 allocation, by reducing the number of tlb misses and by speeding
847 up the pagetable walking.
848
849 If memory constrained on embedded, you may want to say N.
850
851if TRANSPARENT_HUGEPAGE
852
853choice
854 prompt "Transparent Hugepage Support sysfs defaults"
855 default TRANSPARENT_HUGEPAGE_ALWAYS
856 help
857 Selects the sysfs defaults for Transparent Hugepage Support.
858
859 config TRANSPARENT_HUGEPAGE_ALWAYS
860 bool "always"
861 help
862 Enabling Transparent Hugepage always, can increase the
863 memory footprint of applications without a guaranteed
864 benefit but it will work automatically for all applications.
865
866 config TRANSPARENT_HUGEPAGE_MADVISE
867 bool "madvise"
868 help
869 Enabling Transparent Hugepage madvise, will only provide a
870 performance improvement benefit to the applications using
871 madvise(MADV_HUGEPAGE) but it won't risk to increase the
872 memory footprint of applications without a guaranteed
873 benefit.
874
875 config TRANSPARENT_HUGEPAGE_NEVER
876 bool "never"
877 help
878 Disable Transparent Hugepage by default. It can still be
879 enabled at runtime via sysfs.
880endchoice
881
882choice
883 prompt "Shmem hugepage allocation defaults"
884 default TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER
885 help
886 Selects the hugepage allocation policy defaults for
887 the internal shmem mount.
888
889 The selection made here can be overridden by using the kernel
890 command line 'transparent_hugepage_shmem=' option.
891
892 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER
893 bool "never"
894 help
895 Disable hugepage allocation for shmem mount by default. It can
896 still be enabled with the kernel command line
897 'transparent_hugepage_shmem=' option or at runtime via sysfs
898 knob. Note that madvise(MADV_COLLAPSE) can still cause
899 transparent huge pages to be obtained even if this mode is
900 specified.
901
902 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ALWAYS
903 bool "always"
904 help
905 Always attempt to allocate hugepage for shmem mount, can
906 increase the memory footprint of applications without a
907 guaranteed benefit but it will work automatically for all
908 applications.
909
910 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_WITHIN_SIZE
911 bool "within_size"
912 help
913 Enable hugepage allocation for shmem mount if the allocation
914 will be fully within the i_size. This configuration also takes
915 into account any madvise(MADV_HUGEPAGE) hints that may be
916 provided by the applications.
917
918 config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ADVISE
919 bool "advise"
920 help
921 Enable hugepage allocation for the shmem mount exclusively when
922 applications supply the madvise(MADV_HUGEPAGE) hint.
923 This ensures that hugepages are used only in response to explicit
924 requests from applications.
925endchoice
926
927choice
928 prompt "Tmpfs hugepage allocation defaults"
929 default TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER
930 help
931 Selects the hugepage allocation policy defaults for
932 the tmpfs mount.
933
934 The selection made here can be overridden by using the kernel
935 command line 'transparent_hugepage_tmpfs=' option.
936
937 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER
938 bool "never"
939 help
940 Disable hugepage allocation for tmpfs mount by default. It can
941 still be enabled with the kernel command line
942 'transparent_hugepage_tmpfs=' option. Note that
943 madvise(MADV_COLLAPSE) can still cause transparent huge pages
944 to be obtained even if this mode is specified.
945
946 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ALWAYS
947 bool "always"
948 help
949 Always attempt to allocate hugepage for tmpfs mount, can
950 increase the memory footprint of applications without a
951 guaranteed benefit but it will work automatically for all
952 applications.
953
954 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_WITHIN_SIZE
955 bool "within_size"
956 help
957 Enable hugepage allocation for tmpfs mount if the allocation
958 will be fully within the i_size. This configuration also takes
959 into account any madvise(MADV_HUGEPAGE) hints that may be
960 provided by the applications.
961
962 config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ADVISE
963 bool "advise"
964 help
965 Enable hugepage allocation for the tmpfs mount exclusively when
966 applications supply the madvise(MADV_HUGEPAGE) hint.
967 This ensures that hugepages are used only in response to explicit
968 requests from applications.
969endchoice
970
971config THP_SWAP
972 def_bool y
973 depends on ARCH_WANTS_THP_SWAP && SWAP && 64BIT
974 help
975 Swap transparent huge pages in one piece, without splitting.
976 XXX: For now, swap cluster backing transparent huge page
977 will be split after swapout.
978
979 For selection by architectures with reasonable THP sizes.
980
981config NO_PAGE_MAPCOUNT
982 bool "No per-page mapcount (EXPERIMENTAL)"
983 help
984 Do not maintain per-page mapcounts for pages part of larger
985 allocations, such as transparent huge pages.
986
987 When this config option is enabled, some interfaces that relied on
988 this information will rely on less-precise per-allocation information
989 instead: for example, using the average per-page mapcount in such
990 a large allocation instead of the per-page mapcount.
991
992 EXPERIMENTAL because the impact of some changes is still unclear.
993
994endif # TRANSPARENT_HUGEPAGE
995
996# simple helper to make the code a bit easier to read
997config PAGE_MAPCOUNT
998 def_bool !NO_PAGE_MAPCOUNT
999
1000#
1001# The architecture supports pgtable leaves that is larger than PAGE_SIZE
1002#
1003config PGTABLE_HAS_HUGE_LEAVES
1004 def_bool TRANSPARENT_HUGEPAGE || HUGETLB_PAGE
1005
1006#
1007# We can end up creating gigantic folio.
1008#
1009config HAVE_GIGANTIC_FOLIOS
1010 def_bool (HUGETLB_PAGE && ARCH_HAS_GIGANTIC_PAGE) || \
1011 (ZONE_DEVICE && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
1012
1013config ASYNC_KERNEL_PGTABLE_FREE
1014 def_bool n
1015
1016# TODO: Allow to be enabled without THP
1017config ARCH_SUPPORTS_HUGE_PFNMAP
1018 def_bool n
1019 depends on TRANSPARENT_HUGEPAGE
1020
1021config ARCH_SUPPORTS_PMD_PFNMAP
1022 def_bool y
1023 depends on ARCH_SUPPORTS_HUGE_PFNMAP && HAVE_ARCH_TRANSPARENT_HUGEPAGE
1024
1025config ARCH_SUPPORTS_PUD_PFNMAP
1026 def_bool y
1027 depends on ARCH_SUPPORTS_HUGE_PFNMAP && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
1028
1029#
1030# Architectures that always use weak definitions for percpu
1031# variables in modules should set this.
1032#
1033config ARCH_MODULE_NEEDS_WEAK_PER_CPU
1034 bool
1035
1036#
1037# UP and nommu archs use km based percpu allocator
1038#
1039config NEED_PER_CPU_KM
1040 depends on !SMP || !MMU
1041 bool
1042 default y
1043
1044config NEED_PER_CPU_EMBED_FIRST_CHUNK
1045 bool
1046
1047config NEED_PER_CPU_PAGE_FIRST_CHUNK
1048 bool
1049
1050config USE_PERCPU_NUMA_NODE_ID
1051 bool
1052
1053config HAVE_SETUP_PER_CPU_AREA
1054 bool
1055
1056config CMA
1057 bool "Contiguous Memory Allocator"
1058 depends on MMU
1059 select MIGRATION
1060 select MEMORY_ISOLATION
1061 help
1062 This enables the Contiguous Memory Allocator which allows other
1063 subsystems to allocate big physically-contiguous blocks of memory.
1064 CMA reserves a region of memory and allows only movable pages to
1065 be allocated from it. This way, the kernel can use the memory for
1066 pagecache and when a subsystem requests for contiguous area, the
1067 allocated pages are migrated away to serve the contiguous request.
1068
1069 If unsure, say "n".
1070
1071config CMA_DEBUGFS
1072 bool "CMA debugfs interface"
1073 depends on CMA && DEBUG_FS
1074 help
1075 Turns on the DebugFS interface for CMA.
1076
1077config CMA_SYSFS
1078 bool "CMA information through sysfs interface"
1079 depends on CMA && SYSFS
1080 help
1081 This option exposes some sysfs attributes to get information
1082 from CMA.
1083
1084config CMA_AREAS
1085 int "Maximum count of the CMA areas"
1086 depends on CMA
1087 default 20 if NUMA
1088 default 8
1089 help
1090 CMA allows to create CMA areas for particular purpose, mainly,
1091 used as device private area. This parameter sets the maximum
1092 number of CMA area in the system.
1093
1094 If unsure, leave the default value "8" in UMA and "20" in NUMA.
1095
1096#
1097# Select this config option from the architecture Kconfig, if available, to set
1098# the max page order for physically contiguous allocations.
1099#
1100config ARCH_FORCE_MAX_ORDER
1101 int
1102
1103#
1104# When ARCH_FORCE_MAX_ORDER is not defined,
1105# the default page block order is MAX_PAGE_ORDER (10) as per
1106# include/linux/mmzone.h.
1107#
1108config PAGE_BLOCK_MAX_ORDER
1109 int "Page Block Order Upper Limit"
1110 range 1 10 if ARCH_FORCE_MAX_ORDER = 0
1111 default 10 if ARCH_FORCE_MAX_ORDER = 0
1112 range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0
1113 default ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0
1114 help
1115 The page block order refers to the power of two number of pages that
1116 are physically contiguous and can have a migrate type associated to
1117 them. The maximum size of the page block order is at least limited by
1118 ARCH_FORCE_MAX_ORDER/MAX_PAGE_ORDER.
1119
1120 This config adds a new upper limit of default page block
1121 order when the page block order is required to be smaller than
1122 ARCH_FORCE_MAX_ORDER/MAX_PAGE_ORDER or other limits
1123 (see include/linux/pageblock-flags.h for details).
1124
1125 Reducing pageblock order can negatively impact THP generation
1126 success rate. If your workloads use THP heavily, please use this
1127 option with caution.
1128
1129 Don't change if unsure.
1130
1131config MEM_SOFT_DIRTY
1132 bool "Track memory changes"
1133 depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS
1134 select PROC_PAGE_MONITOR
1135 help
1136 This option enables memory changes tracking by introducing a
1137 soft-dirty bit on pte-s. This bit it set when someone writes
1138 into a page just as regular dirty bit, but unlike the latter
1139 it can be cleared by hands.
1140
1141 See Documentation/admin-guide/mm/soft-dirty.rst for more details.
1142
1143config GENERIC_EARLY_IOREMAP
1144 bool
1145
1146config STACK_MAX_DEFAULT_SIZE_MB
1147 int "Default maximum user stack size for 32-bit processes (MB)"
1148 default 100
1149 range 8 2048
1150 depends on STACK_GROWSUP && (!64BIT || COMPAT)
1151 help
1152 This is the maximum stack size in Megabytes in the VM layout of 32-bit
1153 user processes when the stack grows upwards (currently only on parisc
1154 arch) when the RLIMIT_STACK hard limit is unlimited.
1155
1156 A sane initial value is 100 MB.
1157
1158config DEFERRED_STRUCT_PAGE_INIT
1159 bool "Defer initialisation of struct pages to kthreads"
1160 depends on SPARSEMEM
1161 depends on !NEED_PER_CPU_KM
1162 depends on 64BIT
1163 depends on !KMSAN
1164 select PADATA
1165 help
1166 Ordinarily all struct pages are initialised during early boot in a
1167 single thread. On very large machines this can take a considerable
1168 amount of time. If this option is set, large machines will bring up
1169 a subset of memmap at boot and then initialise the rest in parallel.
1170 This has a potential performance impact on tasks running early in the
1171 lifetime of the system until these kthreads finish the
1172 initialisation.
1173
1174config PAGE_IDLE_FLAG
1175 bool
1176 select PAGE_EXTENSION if !64BIT
1177 help
1178 This adds PG_idle and PG_young flags to 'struct page'. PTE Accessed
1179 bit writers can set the state of the bit in the flags so that PTE
1180 Accessed bit readers may avoid disturbance.
1181
1182config IDLE_PAGE_TRACKING
1183 bool "Enable idle page tracking"
1184 depends on SYSFS && MMU
1185 select PAGE_IDLE_FLAG
1186 help
1187 This feature allows to estimate the amount of user pages that have
1188 not been touched during a given period of time. This information can
1189 be useful to tune memory cgroup limits and/or for job placement
1190 within a compute cluster.
1191
1192 See Documentation/admin-guide/mm/idle_page_tracking.rst for
1193 more details.
1194
1195# Architectures which implement cpu_dcache_is_aliasing() to query
1196# whether the data caches are aliased (VIVT or VIPT with dcache
1197# aliasing) need to select this.
1198config ARCH_HAS_CPU_CACHE_ALIASING
1199 bool
1200
1201config ARCH_HAS_CACHE_LINE_SIZE
1202 bool
1203
1204config ARCH_HAS_CURRENT_STACK_POINTER
1205 bool
1206 help
1207 In support of HARDENED_USERCOPY performing stack variable lifetime
1208 checking, an architecture-agnostic way to find the stack pointer
1209 is needed. Once an architecture defines an unsigned long global
1210 register alias named "current_stack_pointer", this config can be
1211 selected.
1212
1213config ARCH_HAS_ZONE_DMA_SET
1214 bool
1215
1216config ZONE_DMA
1217 bool "Support DMA zone" if ARCH_HAS_ZONE_DMA_SET
1218 default y if ARM64 || X86
1219
1220config ZONE_DMA32
1221 bool "Support DMA32 zone" if ARCH_HAS_ZONE_DMA_SET
1222 depends on !X86_32
1223 default y if ARM64
1224
1225config ZONE_DEVICE
1226 bool "Device memory (pmem, HMM, etc...) hotplug support"
1227 depends on MEMORY_HOTREMOVE
1228 select XARRAY_MULTI
1229
1230 help
1231 Device memory hotplug support allows for establishing pmem,
1232 or other device driver discovered memory regions, in the
1233 memmap. This allows pfn_to_page() lookups of otherwise
1234 "device-physical" addresses which is needed for DAX, PCI_P2PDMA, and
1235 DEVICE_PRIVATE features among others.
1236
1237 Enabling this option will reduce the entropy of x86 KASLR memory
1238 regions. For example - on a 46 bit system, the entropy goes down
1239 from 16 bits to 15 bits. The actual reduction in entropy depends
1240 on the physical address bits, on processor features, kernel config
1241 (5 level page table) and physical memory present on the system.
1242
1243#
1244# Helpers to mirror range of the CPU page tables of a process into device page
1245# tables.
1246#
1247config HMM_MIRROR
1248 bool
1249 depends on MMU
1250 select MMU_NOTIFIER
1251
1252config GET_FREE_REGION
1253 bool
1254
1255config DEVICE_PRIVATE
1256 bool "Unaddressable device memory (GPU memory, ...)"
1257 depends on ZONE_DEVICE
1258 select GET_FREE_REGION
1259
1260 help
1261 Allows creation of struct pages to represent unaddressable device
1262 memory; i.e., memory that is only accessible from the device (or
1263 group of devices). You likely also want to select HMM_MIRROR.
1264
1265config VMAP_PFN
1266 bool
1267
1268config ARCH_USES_HIGH_VMA_FLAGS
1269 bool
1270config ARCH_HAS_PKEYS
1271 bool
1272
1273config ARCH_USES_PG_ARCH_2
1274 bool
1275config ARCH_USES_PG_ARCH_3
1276 bool
1277
1278config VM_EVENT_COUNTERS
1279 default y
1280 bool "Enable VM event counters for /proc/vmstat" if EXPERT
1281 help
1282 VM event counters are needed for event counts to be shown.
1283 This option allows the disabling of the VM event counters
1284 on EXPERT systems. /proc/vmstat will only show page counts
1285 if VM event counters are disabled.
1286
1287config PERCPU_STATS
1288 bool "Collect percpu memory statistics"
1289 help
1290 This feature collects and exposes statistics via debugfs. The
1291 information includes global and per chunk statistics, which can
1292 be used to help understand percpu memory usage.
1293
1294config GUP_TEST
1295 bool "Enable infrastructure for get_user_pages()-related unit tests"
1296 depends on DEBUG_FS
1297 help
1298 Provides /sys/kernel/debug/gup_test, which in turn provides a way
1299 to make ioctl calls that can launch kernel-based unit tests for
1300 the get_user_pages*() and pin_user_pages*() family of API calls.
1301
1302 These tests include benchmark testing of the _fast variants of
1303 get_user_pages*() and pin_user_pages*(), as well as smoke tests of
1304 the non-_fast variants.
1305
1306 There is also a sub-test that allows running dump_page() on any
1307 of up to eight pages (selected by command line args) within the
1308 range of user-space addresses. These pages are either pinned via
1309 pin_user_pages*(), or pinned via get_user_pages*(), as specified
1310 by other command line arguments.
1311
1312 See tools/testing/selftests/mm/gup_test.c
1313
1314comment "GUP_TEST needs to have DEBUG_FS enabled"
1315 depends on !GUP_TEST && !DEBUG_FS
1316
1317config GUP_GET_PXX_LOW_HIGH
1318 bool
1319
1320config DMAPOOL_TEST
1321 tristate "Enable a module to run time tests on dma_pool"
1322 depends on HAS_DMA
1323 help
1324 Provides a test module that will allocate and free many blocks of
1325 various sizes and report how long it takes. This is intended to
1326 provide a consistent way to measure how changes to the
1327 dma_pool_alloc/free routines affect performance.
1328
1329config ARCH_HAS_PTE_SPECIAL
1330 bool
1331
1332config MAPPING_DIRTY_HELPERS
1333 bool
1334
1335config KMAP_LOCAL
1336 bool
1337
1338config KMAP_LOCAL_NON_LINEAR_PTE_ARRAY
1339 bool
1340
1341config MEMFD_CREATE
1342 bool "Enable memfd_create() system call" if EXPERT
1343
1344config SECRETMEM
1345 default y
1346 bool "Enable memfd_secret() system call" if EXPERT
1347 depends on ARCH_HAS_SET_DIRECT_MAP
1348 help
1349 Enable the memfd_secret() system call with the ability to create
1350 memory areas visible only in the context of the owning process and
1351 not mapped to other processes and other kernel page tables.
1352
1353config ANON_VMA_NAME
1354 bool "Anonymous VMA name support"
1355 depends on PROC_FS && ADVISE_SYSCALLS && MMU
1356
1357 help
1358 Allow naming anonymous virtual memory areas.
1359
1360 This feature allows assigning names to virtual memory areas. Assigned
1361 names can be later retrieved from /proc/pid/maps and /proc/pid/smaps
1362 and help identifying individual anonymous memory areas.
1363 Assigning a name to anonymous virtual memory area might prevent that
1364 area from being merged with adjacent virtual memory areas due to the
1365 difference in their name.
1366
1367config HAVE_ARCH_USERFAULTFD_WP
1368 bool
1369 help
1370 Arch has userfaultfd write protection support
1371
1372config HAVE_ARCH_USERFAULTFD_MINOR
1373 bool
1374 help
1375 Arch has userfaultfd minor fault support
1376
1377config USERFAULTFD_RWP
1378 def_bool y
1379 depends on 64BIT && ARCH_HAS_PTE_PROTNONE && HAVE_ARCH_USERFAULTFD_WP
1380 help
1381 Userfaultfd read-write protection (UFFDIO_RWPROTECT) delivers a
1382 userfaultfd notification on every access -- read or write -- to a
1383 protected range, letting userspace observe the working set of a
1384 process.
1385
1386menuconfig USERFAULTFD
1387 bool "Enable userfaultfd() system call"
1388 depends on MMU
1389 help
1390 Enable the userfaultfd() system call that allows to intercept and
1391 handle page faults in userland.
1392
1393config PTE_MARKER_UFFD_WP
1394 bool "Userfaultfd write protection support for shmem/hugetlbfs"
1395 default y
1396 depends on USERFAULTFD && HAVE_ARCH_USERFAULTFD_WP
1397
1398 help
1399 Allows to create marker PTEs for userfaultfd write protection
1400 purposes. It is required to enable userfaultfd write protection on
1401 file-backed memory types like shmem and hugetlbfs.
1402
1403# multi-gen LRU {
1404config LRU_GEN
1405 bool "Multi-Gen LRU"
1406 depends on MMU
1407 # make sure folio->flags has enough spare bits
1408 depends on 64BIT || !SPARSEMEM || SPARSEMEM_VMEMMAP
1409 help
1410 A high performance LRU implementation to overcommit memory. See
1411 Documentation/admin-guide/mm/multigen_lru.rst for details.
1412
1413config LRU_GEN_ENABLED
1414 bool "Enable by default"
1415 depends on LRU_GEN
1416 help
1417 This option enables the multi-gen LRU by default.
1418
1419config LRU_GEN_STATS
1420 bool "Full stats for debugging"
1421 depends on LRU_GEN
1422 help
1423 Do not enable this option unless you plan to look at historical stats
1424 from evicted generations for debugging purpose.
1425
1426 This option has a per-memcg and per-node memory overhead.
1427
1428config LRU_GEN_WALKS_MMU
1429 def_bool y
1430 depends on LRU_GEN && ARCH_HAS_HW_PTE_YOUNG
1431# }
1432
1433config ARCH_SUPPORTS_PER_VMA_LOCK
1434 def_bool n
1435
1436config PER_VMA_LOCK
1437 def_bool y
1438 depends on ARCH_SUPPORTS_PER_VMA_LOCK && MMU && SMP
1439 help
1440 Allow per-vma locking during page fault handling.
1441
1442 This feature allows locking each virtual memory area separately when
1443 handling page faults instead of taking mmap_lock.
1444
1445config LOCK_MM_AND_FIND_VMA
1446 bool
1447 depends on !STACK_GROWSUP
1448
1449config IOMMU_MM_DATA
1450 bool
1451
1452config EXECMEM
1453 bool
1454
1455config NUMA_MEMBLKS
1456 bool
1457
1458config NUMA_EMU
1459 bool "NUMA emulation"
1460 depends on NUMA_MEMBLKS
1461 depends on X86 || GENERIC_ARCH_NUMA
1462 help
1463 Enable NUMA emulation. A flat machine will be split
1464 into virtual nodes when booted with "numa=fake=N", where N is the
1465 number of nodes. This is only useful for debugging.
1466
1467config GENERIC_ARCH_NUMA
1468 bool
1469 select NUMA_MEMBLKS
1470 help
1471 Enable support for generic NUMA implementation. Currently, RISC-V
1472 and ARM64 use it.
1473
1474config ARCH_HAS_USER_SHADOW_STACK
1475 bool
1476 help
1477 The architecture has hardware support for userspace shadow call
1478 stacks (eg, x86 CET, arm64 GCS or RISC-V Zicfiss).
1479
1480config HAVE_ARCH_TLB_REMOVE_TABLE
1481 def_bool n
1482
1483config PT_RECLAIM
1484 def_bool y
1485 depends on MMU_GATHER_RCU_TABLE_FREE && !HAVE_ARCH_TLB_REMOVE_TABLE
1486 help
1487 Try to reclaim empty user page table pages in paths other than munmap
1488 and exit_mmap path.
1489
1490 Note: now only empty user PTE page table pages will be reclaimed.
1491
1492config FIND_NORMAL_PAGE
1493 def_bool n
1494
1495config ARCH_HAS_LAZY_MMU_MODE
1496 bool
1497 help
1498 The architecture uses the lazy MMU mode. This allows changes to
1499 MMU-related architectural state to be deferred until the mode is
1500 exited. See <linux/pgtable.h> for details.
1501
1502config LAZY_MMU_MODE_KUNIT_TEST
1503 tristate "KUnit tests for the lazy MMU mode" if !KUNIT_ALL_TESTS
1504 depends on ARCH_HAS_LAZY_MMU_MODE
1505 depends on KUNIT
1506 default KUNIT_ALL_TESTS
1507 help
1508 Enable this option to check that the lazy MMU mode interface behaves
1509 as expected. Only tests for the generic interface are included (not
1510 architecture-specific behaviours).
1511
1512 If unsure, say N.
1513
1514source "mm/damon/Kconfig"
1515
1516endmenu