LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 1/4] mm: Kconfig: move swap and slab config options to the MM section
Date: Tue, 24 Aug 2021 13:47:08 +0200	[thread overview]
Message-ID: <5a440ea3-da45-49d9-f3c6-de7be31f69bb@suse.cz> (raw)
In-Reply-To: <20210819195533.211756-1-hannes@cmpxchg.org>

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@cmpxchg.org>

Acked-by: Vlastimil Babka <vbabka@suse.cz>

> ---
>  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
> 


      parent reply	other threads:[~2021-08-24 11:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19 19:55 Johannes Weiner
2021-08-19 19:55 ` [PATCH 2/4] mm: Kconfig: group swap, slab, hotplug and thp options into submenus Johannes Weiner
2021-08-24 12:03   ` Vlastimil Babka
2021-08-24 14:56     ` Johannes Weiner
2021-08-19 19:55 ` [PATCH 3/4] mm: Kconfig: simplify zswap configuration Johannes Weiner
2021-08-24 12:04   ` Vlastimil Babka
2021-08-19 19:55 ` [PATCH 4/4] mm: zswap: add basic meminfo and vmstat coverage Johannes Weiner
2021-08-24 12:05   ` Vlastimil Babka
2021-08-30 18:04   ` kernel test robot
2021-08-30 18:49   ` Minchan Kim
2021-11-02 15:06     ` Johannes Weiner
2021-11-10 19:11       ` Minchan Kim
2021-08-24 11:47 ` Vlastimil Babka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a440ea3-da45-49d9-f3c6-de7be31f69bb@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --subject='Re: [PATCH 1/4] mm: Kconfig: move swap and slab config options to the MM section' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).