# SPDX-License-Identifier: GPL-2.0-only menu "Memory Management options" ## For some reason microblaze and nios2 hard code SWAP=n.  Hopefully we can# add proper SWAP support to them, in which case this can be remove.#config ARCH_NO_SWAP	bool menuconfig SWAP	bool "Support for paging of anonymous memory (swap)"	depends on MMU && BLOCK && !ARCH_NO_SWAP	default y	help	  This option allows you to choose whether you want to have support	  for so called swap devices or swap files in your kernel that are	  used to provide more virtual memory than the actual RAM present	  in your computer.  If unsure say Y. config ZSWAP	bool "Compressed cache for swap pages"	depends on SWAP	select CRYPTO	select ZSMALLOC	help	  A lightweight compressed cache for swap pages.  It takes	  pages that are in the process of being swapped out and attempts to	  compress them into a dynamically allocated RAM-based memory pool.	  This can result in a significant I/O reduction on swap device and,	  in the case where decompressing from RAM is faster than swap device	  reads, can also improve workload performance. config ZSWAP_DEFAULT_ON	bool "Enable the compressed cache for swap pages by default"	depends on ZSWAP	help	  If selected, the compressed cache for swap pages will be enabled	  at boot, otherwise it will be disabled. 	  The selection made here can be overridden by using the kernel	  command line 'zswap.enabled=' option. config ZSWAP_SHRINKER_DEFAULT_ON	bool "Shrink the zswap pool on memory pressure"	depends on ZSWAP	default n	help	  If selected, the zswap shrinker will be enabled, and the pages	  stored in the zswap pool will become available for reclaim (i.e	  written back to the backing swap device) on memory pressure. 	  This means that zswap writeback could happen even if the pool is	  not yet full, or the cgroup zswap limit has not been reached,	  reducing the chance that cold pages will reside in the zswap pool	  and consume memory indefinitely. choice	prompt "Default compressor"	depends on ZSWAP	default ZSWAP_COMPRESSOR_DEFAULT_LZO	help	  Selects the default compression algorithm for the compressed cache	  for swap pages. 	  For an overview what kind of performance can be expected from	  a particular compression algorithm please refer to the benchmarks	  available at the following LWN page:	  https://lwn.net/Articles/751795/ 	  If in doubt, select 'LZO'. 	  The selection made here can be overridden by using the kernel	  command line 'zswap.compressor=' option. config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE	bool "Deflate"	select CRYPTO_DEFLATE	help	  Use the Deflate algorithm as the default compression algorithm. config ZSWAP_COMPRESSOR_DEFAULT_LZO	bool "LZO"	select CRYPTO_LZO	help	  Use the LZO algorithm as the default compression algorithm. config ZSWAP_COMPRESSOR_DEFAULT_842	bool "842"	select CRYPTO_842	help	  Use the 842 algorithm as the default compression algorithm. config ZSWAP_COMPRESSOR_DEFAULT_LZ4	bool "LZ4"	select CRYPTO_LZ4	help	  Use the LZ4 algorithm as the default compression algorithm. config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC	bool "LZ4HC"	select CRYPTO_LZ4HC	help	  Use the LZ4HC algorithm as the default compression algorithm. config ZSWAP_COMPRESSOR_DEFAULT_ZSTD	bool "zstd"	select CRYPTO_ZSTD	help	  Use the zstd algorithm as the default compression algorithm.endchoice config ZSWAP_COMPRESSOR_DEFAULT       string       depends on ZSWAP       default "deflate" if ZSWAP_COMPRESSOR_DEFAULT_DEFLATE       default "lzo" if ZSWAP_COMPRESSOR_DEFAULT_LZO       default "842" if ZSWAP_COMPRESSOR_DEFAULT_842       default "lz4" if ZSWAP_COMPRESSOR_DEFAULT_LZ4       default "lz4hc" if ZSWAP_COMPRESSOR_DEFAULT_LZ4HC       default "zstd" if ZSWAP_COMPRESSOR_DEFAULT_ZSTD       default "" config ZSMALLOC	tristate menu "Zsmalloc allocator options"	depends on ZSMALLOC comment "Zsmalloc is a common backend allocator for zswap & zram" config ZSMALLOC_STAT	bool "Export zsmalloc statistics"	select DEBUG_FS	help	  This option enables code in the zsmalloc to collect various	  statistics about what's happening in zsmalloc and exports that	  information to userspace via debugfs.	  If unsure, say N. config ZSMALLOC_CHAIN_SIZE	int "Maximum number of physical pages per-zspage"	default 8	range 4 16	help	  This option sets the upper limit on the number of physical pages	  that a zmalloc page (zspage) can consist of. The optimal zspage	  chain size is calculated for each size class during the	  initialization of the pool. 	  Changing this option can alter the characteristics of size classes,	  such as the number of pages per zspage and the number of objects	  per zspage. This can also result in different configurations of	  the pool, as zsmalloc merges size classes with similar	  characteristics. 	  For more information, see zsmalloc documentation. endmenu menu "Slab allocator options" config SLUB	def_bool y	select IRQ_WORK config KVFREE_RCU_BATCHED	def_bool y	depends on !SLUB_TINY && !TINY_RCU	depends on !RCU_STRICT_GRACE_PERIOD config SLUB_TINY	bool "Configure for minimal memory footprint"	depends on EXPERT && !COMPILE_TEST	select SLAB_MERGE_DEFAULT	help	   Configures the slab allocator in a way to achieve minimal memory	   footprint, sacrificing scalability, debugging and other features.	   This is intended only for the smallest system that had used the	   SLOB allocator and is not recommended for systems with more than	   16MB RAM. 	   If unsure, say N. config SLAB_MERGE_DEFAULT	bool "Allow slab caches to be merged"	default y	help	  For reduced kernel memory fragmentation, slab caches can be	  merged when they share the same size and other characteristics.	  This carries a risk of kernel heap overflows being able to	  overwrite objects from merged caches (and more easily control	  cache layout), which makes such heap attacks easier to exploit	  by attackers. By keeping caches unmerged, these kinds of exploits	  can usually only damage objects in the same cache. To disable	  merging at runtime, "slab_nomerge" can be passed on the kernel	  command line. config SLAB_FREELIST_RANDOM	bool "Randomize slab freelist"	depends on !SLUB_TINY	help	  Randomizes the freelist order used on creating new pages. This	  security feature reduces the predictability of the kernel slab	  allocator against heap overflows. config SLAB_FREELIST_HARDENED	bool "Harden slab freelist metadata"	depends on !SLUB_TINY	help	  Many kernel heap attacks try to target slab cache metadata and	  other infrastructure. This options makes minor performance	  sacrifices to harden the kernel slab allocator against common	  freelist exploit methods. config SLAB_BUCKETS	bool "Support allocation from separate kmalloc buckets"	depends on !SLUB_TINY	default SLAB_FREELIST_HARDENED	help	  Kernel heap attacks frequently depend on being able to create	  specifically-sized allocations with user-controlled contents	  that will be allocated into the same kmalloc bucket as a	  target object. To avoid sharing these allocation buckets,	  provide an explicitly separated set of buckets to be used for	  user-controlled allocations. This may very slightly increase	  memory fragmentation, though in practice it's only a handful	  of extra pages since the bulk of user-controlled allocations	  are relatively long-lived. 	  If unsure, say Y. config SLUB_STATS	default n	bool "Enable performance statistics"	depends on SYSFS && !SLUB_TINY	help	  The statistics are useful to debug slab allocation behavior in	  order find ways to optimize the allocator. This should never be	  enabled for production use since keeping statistics slows down	  the allocator by a few percentage points. The slabinfo command	  supports the determination of the most active slabs to figure	  out which slabs are relevant to a particular load.	  Try running: slabinfo -DA config KMALLOC_PARTITION_CACHES	depends on !SLUB_TINY	bool "Partitioned slab caches for normal kmalloc"	default RANDOM_KMALLOC_CACHES	help	  A hardening feature that creates multiple isolated copies of slab	  caches for normal kmalloc allocations. This makes it more difficult	  to exploit memory-safety vulnerabilities by attacking vulnerable	  co-located memory objects. Several modes are provided. 	  Currently the number of copies is set to 16, a reasonably large value	  that effectively diverges the memory objects allocated for different	  subsystems or modules into different caches, at the expense of a	  limited degree of memory and CPU overhead that relates to hardware	  and system workload. choice	prompt "Partitioned slab cache mode"	depends on KMALLOC_PARTITION_CACHES	default KMALLOC_PARTITION_TYPED if CC_HAS_ALLOC_TOKEN	default KMALLOC_PARTITION_RANDOM	help	  Selects the slab cache partitioning mode. config KMALLOC_PARTITION_RANDOM	bool "Randomize slab caches for normal kmalloc"	help	  Randomly pick a slab cache based on code address and a per-boot	  random seed. 	  This makes it harder for attackers to predict object co-location.	  The placement is random: while attackers don't know which kmalloc	  cache an object will be allocated from, they might circumvent	  the randomization by retrying attacks across multiple machines until	  the target objects are co-located. config KMALLOC_PARTITION_TYPED	bool "Type based slab cache selection for normal kmalloc"	depends on CC_HAS_ALLOC_TOKEN	help	  Rely on Clang's allocation tokens to choose a slab cache, where token	  IDs are derived from the allocated type. 	  Unlike KMALLOC_PARTITION_RANDOM, cache assignment is deterministic based	  on type, which guarantees that objects of certain types are not	  placed in the same cache. This effectively mitigates certain classes	  of exploits that probabilistic defenses like KMALLOC_PARTITION_RANDOM	  only make harder but not impossible. However, this also means the	  cache assignment is predictable. 	  Clang's default token ID calculation returns a bounded hash with	  disjoint ranges for pointer-containing and pointerless objects: when	  used as the slab cache index, this prevents buffer overflows on	  primitive buffers from directly corrupting pointer-containing	  objects. 	  The current effectiveness of Clang's type inference can be judged by	  -Rpass=alloc-token, which provides diagnostics where (after dead-code	  elimination) type inference failed. 	  Requires Clang 22 or later. endchoice config RANDOM_KMALLOC_CACHES	bool	transitional	help	  Transitional config for migration to KMALLOC_PARTITION_CACHES. endmenu # Slab allocator options config SHUFFLE_PAGE_ALLOCATOR	bool "Page allocator randomization"	default SLAB_FREELIST_RANDOM && ACPI_NUMA	help	  Randomization of the page allocator improves the average	  utilization of a direct-mapped memory-side-cache. See section	  5.2.27 Heterogeneous Memory Attribute Table (HMAT) in the ACPI	  6.2a specification for an example of how a platform advertises	  the presence of a memory-side-cache. There are also incidental	  security benefits as it reduces the predictability of page	  allocations to compliment SLAB_FREELIST_RANDOM, but the	  default granularity of shuffling on the MAX_PAGE_ORDER i.e, 10th	  order of pages is selected based on cache utilization benefits	  on x86. 	  While the randomization improves cache utilization it may	  negatively impact workloads on platforms without a cache. For	  this reason, by default, the randomization is not enabled even	  if SHUFFLE_PAGE_ALLOCATOR=y. The randomization may be force enabled	  with the 'page_alloc.shuffle' kernel command line parameter. 	  Say Y if unsure. config COMPAT_BRK	bool "Disable heap randomization"	default y	help	  Randomizing heap placement makes heap exploits harder, but it	  also breaks ancient binaries (including anything libc5 based).	  This option changes the bootup default to heap randomization	  disabled, and can be overridden at runtime by setting	  /proc/sys/kernel/randomize_va_space to 2. 	  On non-ancient distros (post-2000 ones) N is usually a safe choice. config MMAP_ALLOW_UNINITIALIZED	bool "Allow mmapped anonymous memory to be uninitialized"	depends on EXPERT && !MMU	default n	help	  Normally, and according to the Linux spec, anonymous memory obtained	  from mmap() has its contents cleared before it is passed to	  userspace.  Enabling this config option allows you to request that	  mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus	  providing a huge performance boost.  If this option is not enabled,	  then the flag will be ignored. 	  This is taken advantage of by uClibc's malloc(), and also by	  ELF-FDPIC binfmt's brk and stack allocator. 	  Because of the obvious security issues, this option should only be	  enabled on embedded devices where you control what is run in	  userspace.  Since that isn't generally a problem on no-MMU systems,	  it is normally safe to say Y here. 	  See Documentation/admin-guide/mm/nommu-mmap.rst for more information. config SELECT_MEMORY_MODEL	def_bool y	depends on ARCH_SELECT_MEMORY_MODEL choice	prompt "Memory model"	depends on SELECT_MEMORY_MODEL	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 !NUMA	depends on !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 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 SPARSEMEM	def_bool y	depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL config FLATMEM	def_bool y	depends on !NUMA	depends on !SPARSEMEM || FLATMEM_MANUAL ## 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	def_bool y	depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE	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 SPARSEMEM_VMEMMAP_PREINIT	bool## Select this config option from the architecture Kconfig, if it is preferred# to enable the feature of HugeTLB/dev_dax vmemmap optimization.#config ARCH_WANT_OPTIMIZE_DAX_VMEMMAP	bool config ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP	bool config ARCH_WANT_HUGETLB_VMEMMAP_PREINIT	bool config HAVE_MEMBLOCK_PHYS_MAP	bool config HAVE_GUP_FAST	depends on MMU	bool # Enable memblock support for scratch memory which is needed for kexec handoverconfig MEMBLOCK_KHO_SCRATCH	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

Lines 1–500 of 1516. Load more