Re: [PATCH 1/4] mm: Kconfig: move swap and slab config options to the MM section

[Vlastimil Babka]

On 8/19/21 21:55, Johannes Weiner wrote:
> These are currently under General Setup. MM seems like a better fit.

Right. I've been also wondering about that occasionally.

> Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>

Acked-by: Vlastimil Babka <vbabka@xxxxxxx>

> ---
>  init/Kconfig | 120 ---------------------------------------------------
>  mm/Kconfig   | 120 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 120 insertions(+), 120 deletions(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index a61c92066c2e..a2358cd5498a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -331,23 +331,6 @@ config DEFAULT_HOSTNAME
>  	  but you may wish to use a different default here to make a minimal
>  	  system more usable with less configuration.
>  
> -#
> -# 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
> -
> -config 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 SYSVIPC
>  	bool "System V IPC"
>  	help
> @@ -1862,109 +1845,6 @@ config COMPAT_BRK
>  
>  	  On non-ancient distros (post-2000 ones) N is usually a safe choice.
>  
> -choice
> -	prompt "Choose SLAB allocator"
> -	default SLUB
> -	help
> -	   This option allows to select a slab allocator.
> -
> -config SLAB
> -	bool "SLAB"
> -	select HAVE_HARDENED_USERCOPY_ALLOCATOR
> -	help
> -	  The regular slab allocator that is established and known to work
> -	  well in all environments. It organizes cache hot objects in
> -	  per cpu and per node queues.
> -
> -config SLUB
> -	bool "SLUB (Unqueued Allocator)"
> -	select HAVE_HARDENED_USERCOPY_ALLOCATOR
> -	help
> -	   SLUB is a slab allocator that minimizes cache line usage
> -	   instead of managing queues of cached objects (SLAB approach).
> -	   Per cpu caching is realized using slabs of objects instead
> -	   of queues of objects. SLUB can use memory efficiently
> -	   and has enhanced diagnostics. SLUB is the default choice for
> -	   a slab allocator.
> -
> -config SLOB
> -	depends on EXPERT
> -	bool "SLOB (Simple Allocator)"
> -	help
> -	   SLOB replaces the stock allocator with a drastically simpler
> -	   allocator. SLOB is generally more space efficient but
> -	   does not perform as well on large systems.
> -
> -endchoice
> -
> -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 SLAB || SLUB
> -	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 SLAB || SLUB
> -	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. Some slab implementations have more
> -	  sanity-checking than others. This option is most effective with
> -	  CONFIG_SLUB.
> -
> -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_ORDER - 1" 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 enabled only
> -	  after runtime detection of a direct-mapped memory-side-cache.
> -	  Otherwise, the randomization may be force enabled with the
> -	  'page_alloc.shuffle' kernel command line parameter.
> -
> -	  Say Y if unsure.
> -
> -config SLUB_CPU_PARTIAL
> -	default y
> -	depends on SLUB && SMP
> -	bool "SLUB per cpu partial cache"
> -	help
> -	  Per cpu partial caches accelerate objects allocation and freeing
> -	  that is local to a processor at the price of more indeterminism
> -	  in the latency of the free. On overflow these caches will be cleared
> -	  which requires the taking of locks that may cause latency spikes.
> -	  Typically one would choose no for a realtime system.
> -
>  config MMAP_ALLOW_UNINITIALIZED
>  	bool "Allow mmapped anonymous memory to be uninitialized"
>  	depends on EXPERT && !MMU
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 02d44e3420f5..894858536e7f 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -2,6 +2,126 @@
>  
>  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
> +
> +config 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.
> +
> +choice
> +	prompt "Choose SLAB allocator"
> +	default SLUB
> +	help
> +	   This option allows to select a slab allocator.
> +
> +config SLAB
> +	bool "SLAB"
> +	select HAVE_HARDENED_USERCOPY_ALLOCATOR
> +	help
> +	  The regular slab allocator that is established and known to work
> +	  well in all environments. It organizes cache hot objects in
> +	  per cpu and per node queues.
> +
> +config SLUB
> +	bool "SLUB (Unqueued Allocator)"
> +	select HAVE_HARDENED_USERCOPY_ALLOCATOR
> +	help
> +	   SLUB is a slab allocator that minimizes cache line usage
> +	   instead of managing queues of cached objects (SLAB approach).
> +	   Per cpu caching is realized using slabs of objects instead
> +	   of queues of objects. SLUB can use memory efficiently
> +	   and has enhanced diagnostics. SLUB is the default choice for
> +	   a slab allocator.
> +
> +config SLOB
> +	depends on EXPERT
> +	bool "SLOB (Simple Allocator)"
> +	help
> +	   SLOB replaces the stock allocator with a drastically simpler
> +	   allocator. SLOB is generally more space efficient but
> +	   does not perform as well on large systems.
> +
> +endchoice
> +
> +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 SLAB || SLUB
> +	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 SLAB || SLUB
> +	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. Some slab implementations have more
> +	  sanity-checking than others. This option is most effective with
> +	  CONFIG_SLUB.
> +
> +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_ORDER - 1" 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 enabled only
> +	  after runtime detection of a direct-mapped memory-side-cache.
> +	  Otherwise, the randomization may be force enabled with the
> +	  'page_alloc.shuffle' kernel command line parameter.
> +
> +	  Say Y if unsure.
> +
> +config SLUB_CPU_PARTIAL
> +	default y
> +	depends on SLUB && SMP
> +	bool "SLUB per cpu partial cache"
> +	help
> +	  Per cpu partial caches accelerate objects allocation and freeing
> +	  that is local to a processor at the price of more indeterminism
> +	  in the latency of the free. On overflow these caches will be cleared
> +	  which requires the taking of locks that may cause latency spikes.
> +	  Typically one would choose no for a realtime system.
> +
>  config SELECT_MEMORY_MODEL
>  	def_bool y
>  	depends on ARCH_SELECT_MEMORY_MODEL
>