path: root/mm/Kconfig

# SPDX-License-Identifier: GPL-2.0-only

menu "Memory Management options"

config SELECT_MEMORY_MODEL
	def_bool y
	depends on ARCH_SELECT_MEMORY_MODEL

choice
	prompt "Memory model"
	depends on SELECT_MEMORY_MODEL
	default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT
	default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT
	default FLATMEM_MANUAL
	help
	  This option allows you to change some of the ways that
	  Linux manages its memory internally. Most users will
	  only have one option here selected by the architecture
	  configuration. This is normal.

config FLATMEM_MANUAL
	bool "Flat Memory"
	depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE
	help
	  This option is best suited for non-NUMA systems with
	  flat address space. The FLATMEM is the most efficient
	  system in terms of performance and resource consumption
	  and it is the best option for smaller systems.

	  For systems that have holes in their physical address
	  spaces and for features like NUMA and memory hotplug,
	  choose "Sparse Memory".

	  If unsure, choose this option (Flat Memory) over any other.

config DISCONTIGMEM_MANUAL
	bool "Discontiguous Memory"
	depends on ARCH_DISCONTIGMEM_ENABLE
	help
	  This option provides enhanced support for discontiguous
	  memory systems, over FLATMEM.  These systems have holes
	  in their physical address spaces, and this option provides
	  more efficient handling of these holes.

	  Although "Discontiguous Memory" is still used by several
	  architectures, it is considered deprecated in favor of
	  "Sparse Memory".

	  If unsure, choose "Sparse Memory" over this option.

config SPARSEMEM_MANUAL
	bool "Sparse Memory"
	depends on ARCH_SPARSEMEM_ENABLE
	help
	  This will be the only option for some systems, including
	  memory hot-plug systems.  This is normal.

	  This option provides efficient support for systems with
	  holes is their physical address space and allows memory
	  hot-plug and hot-remove.

	  If unsure, choose "Flat Memory" over this option.

endchoice

config DISCONTIGMEM
	def_bool y
	depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL

config SPARSEMEM
	def_bool y
	depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL

config FLATMEM
	def_bool y
	depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL

config FLAT_NODE_MEM_MAP
	def_bool y
	depends on !SPARSEMEM

#
# Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's
# to represent different areas of memory.  This variable allows
# those dependencies to exist individually.
#
config NEED_MULTIPLE_NODES
	def_bool y
	depends on DISCONTIGMEM || NUMA

#
# SPARSEMEM_EXTREME (which is the default) does some bootmem
# allocations when sparse_init() is called.  If this cannot
# be done on your architecture, select this option.  However,
# statically allocating the mem_section[] array can potentially
# consume vast quantities of .bss, so be careful.
#
# This option will also potentially produce smaller runtime code
# with gcc 3.4 and later.
#
config SPARSEMEM_STATIC
	bool

#
# Architecture platforms which require a two level mem_section in SPARSEMEM
# must select this option. This is usually for architecture platforms with
# an extremely sparse physical address space.
#
config SPARSEMEM_EXTREME
	def_bool y
	depends on SPARSEMEM && !SPARSEMEM_STATIC

config SPARSEMEM_VMEMMAP_ENABLE
	bool

config SPARSEMEM_VMEMMAP
	bool "Sparse Memory virtual memmap"
	depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE
	default y
	help
	  SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise
	  pfn_to_page and page_to_pfn operations.  This is the most
	  efficient option when sufficient kernel resources are available.

config HAVE_MEMBLOCK_PHYS_MAP
	bool

config HAVE_FAST_GUP
	depends on MMU
	bool

# Don't discard allocated memory used to track "memory" and "reserved" memblocks
# after early boot, so it can still be used to test for validity of memory.
# Also, memblocks are updated with memory hot(un)plug.
config ARCH_KEEP_MEMBLOCK
	bool

# Keep arch NUMA mapping infrastructure post-init.
config NUMA_KEEP_MEMINFO
	bool

config MEMORY_ISOLATION
	bool

#
# Only be set on architectures that have completely implemented memory hotplug
# feature. If you are not sure, don't touch it.
#
config HAVE_BOOTMEM_INFO_NODE
	def_bool n

# eventually, we can have this option just 'select SPARSEMEM'
config MEMORY_HOTPLUG
	bool "Allow for memory hot-add"
	select MEMORY_ISOLATION
	depends on SPARSEMEM || X86_64_ACPI_NUMA
	depends on ARCH_ENABLE_MEMORY_HOTPLUG
	depends on 64BIT || BROKEN
	select NUMA_KEEP_MEMINFO if NUMA

config MEMORY_HOTPLUG_SPARSE
	def_bool y
	depends on SPARSEMEM && MEMORY_HOTPLUG

config MEMORY_HOTPLUG_DEFAULT_ONLINE
	bool "Online the newly added memory blocks by default"
	depends on MEMORY_HOTPLUG
	help
	  This option sets the default policy setting for memory hotplug
	  onlining policy (/sys/devices/system/memory/auto_online_blocks) which
	  determines what happens to newly added memory regions. Policy setting
	  can always be changed at runtime.
	  See Documentation/admin-guide/mm/memory-hotplug.rst for more information.

	  Say Y here if you want all hot-plugged memory blocks to appear in
	  'online' state by default.
	  Say N here if you want the default policy to keep all hot-plugged
	  memory blocks in 'offline' state.

config MEMORY_HOTREMOVE
	bool "Allow for memory hot remove"
	select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
	depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
	depends on MIGRATION

# Heavily threaded applications may benefit from splitting the mm-wide
# page_table_lock, so that faults on different parts of the user address
# space can be handled with less contention: split it at this NR_CPUS.
# Default to 4 for wider testing, though 8 might be more appropriate.
# ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
# PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
# SPARC32 allocates multiple pte tables within a single page, and therefore
# a per-page lock leads to problems when multiple tables need to be locked
# at the same time (e.g. copy_page_range()).
# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page.
#
config SPLIT_PTLOCK_CPUS
	int
	default "999999" if !MMU
	default "999999" if ARM && !CPU_CACHE_VIPT
	default "999999" if PARISC && !PA20
	default "999999" if SPARC32
	default "4"

config ARCH_ENABLE_SPLIT_PMD_PTLOCK
	bool

#
# support for memory balloon
config MEMORY_BALLOON
	bool

#
# support for memory balloon compaction
config BALLOON_COMPACTION
	bool "Allow for balloon memory compaction/migration"
	def_bool y
	depends on COMPACTION && MEMORY_BALLOON
	help
	  Memory fragmentation introduced by ballooning might reduce
	  significantly the number of 2MB contiguous memory blocks that can be
	  used within a guest, thus imposing performance penalties associated
	  with the reduced number of transparent huge pages that could be used
	  by the guest workload. Allowing the compaction & migration for memory
	  pages enlisted as being part of memory balloon devices avoids the
	  scenario aforementioned and helps improving memory defragmentation.

#
# support for memory compaction
config COMPACTION
	bool "Allow for memory compaction"
	def_bool y
	select MIGRATION
	depends on MMU
	help
	  Compaction is the only memory management component to form
	  high order (larger physically contiguous) memory blocks
	  reliably. The page allocator relies on compaction heavily and
	  the lack of the feature can lead to unexpected OOM killer
	  invocations for high order memory requests. You shouldn't
	  disable this option unless there really is a strong reason for
	  it and then we would be really interested to hear about that at
	  linux-mm@kvack.org.

#
# support for free page reporting
config PAGE_REPORTING
	bool "Free page reporting"
	def_bool n
	help
	  Free page reporting allows for the incremental acquisition of
	  free pages from the buddy allocator for the purpose of reporting
	  those pages to another entity, such as a hypervisor, so that the
	  memory can be freed within the host for other uses.

#
# support for page migration
#
config MIGRATION
	bool "Page migration"
	def_bool y
	depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU
	help
	  Allows the migration of the physical location of pages of processes
	  while the virtual addresses are not changed. This is useful in
	  two situations. The first is on NUMA systems to put pages nearer
	  to the processors accessing. The second is when allocating huge
	  pages as migration can relocate pages to satisfy a huge page
	  allocation instead of reclaiming.

config ARCH_ENABLE_HUGEPAGE_MIGRATION
	bool

config ARCH_ENABLE_THP_MIGRATION
	bool

config CONTIG_ALLOC
	def_bool (MEMORY_ISOLATION && COMPACTION) || CMA

config PHYS_ADDR_T_64BIT
	def_bool 64BIT

config BOUNCE
	bool "Enable bounce buffers"
	default y
	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
	help
	  Enable bounce buffers for devices that cannot access
	  the full range of memory available to the CPU. Enabled
	  by default when ZONE_DMA or HIGHMEM is selected, but you
	  may say n to override this.

config VIRT_TO_BUS
	bool
	help
	  An architecture should select this if it implements the
	  deprecated interface virt_to_bus().  All new architectures
	  should probably not select this.


config MMU_NOTIFIER
	bool
	select SRCU
	select INTERVAL_TREE

config KSM
	bool "Enable KSM for page merging"
	depends on MMU
	select XXHASH
	help
	  Enable Kernel Samepage Merging: KSM periodically scans those areas
	  of an application's address space that an app has advised may be
	  mergeable.  When it finds pages of identical content, it replaces
	  the many instances by a single page with that content, so
	  saving memory until one or another app needs to modify the content.
	  Recommended for use with KVM, or with other duplicative applications.
	  See Documentation/vm/ksm.rst for more information: KSM is inactive
	  until a program has madvised that an area is MADV_MERGEABLE, and
	  root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set).

config DEFAULT_MMAP_MIN_ADDR
	int "Low address space to protect from user allocation"
	depends on MMU
	default 4096
	help
	  This is the portion of low virtual memory which should be protected
	  from userspace allocation.  Keeping a user from writing to low pages
	  can help reduce the impact of kernel NULL pointer bugs.

	  For most ia64, ppc64 and x86 users with lots of address space
	  a value of 65536 is reasonable and should cause no problems.
	  On arm and other archs it should not be higher than 32768.
	  Programs which use vm86 functionality or have some need to map
	  this low address space will need CAP_SYS_RAWIO or disable this
	  protection by setting the value to 0.

	  This value can be changed after boot using the
	  /proc/sys/vm/mmap_min_addr tunable.

config ARCH_SUPPORTS_MEMORY_FAILURE
	bool

config MEMORY_FAILURE
	depends on MMU
	depends on ARCH_SUPPORTS_MEMORY_FAILURE
	bool "Enable recovery from hardware memory errors"
	select MEMORY_ISOLATION
	select RAS
	help
	  Enables code to recover from some memory failures on systems
	  with MCA recovery. This allows a system to continue running
	  even when some of its memory has uncorrected errors. This requires
	  special hardware support and typically ECC memory.

config HWPOISON_INJECT
	tristate