linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: Dave Hansen <dave@sr71.net>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 3/3] Kconfig: organize memory-related config options
Date: Wed, 5 Feb 2014 15:28:20 +0100	[thread overview]
Message-ID: <20140205142820.GD2425@dhcp22.suse.cz> (raw)
In-Reply-To: <20140102202017.9D167747@viggo.jf.intel.com>

On Thu 02-01-14 12:20:17, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> This continues in a series of patches to clean up the
> configuration menus.  I believe they've become really hard to
> navigate and there are some simple things we can do to make
> things easier to find.
> 
> This creates a "Memory Options" menu and moves some things like
> swap and slab configuration under them.  It also moves SLUB_DEBUG
> to the debugging menu.
> 
> After this patch, the menu has the following options:
> 
>   [ ] Memory placement aware NUMA scheduler
>   [*] Enable VM event counters for /proc/vmstat
>   [ ] Disable heap randomization
>   [*] Support for paging of anonymous memory (swap)
>       Choose SLAB allocator (SLUB (Unqueued Allocator))
>   [*] SLUB per cpu partial cache
>   [*] SLUB: attempt to use double-cmpxchg operations

Is there any reason to keep them in init/Kconfig rather than
mm/Kconfig? It would sound like a logical place to have them all, no?

> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: linux-mm@kvack.org
> ---
> 
>  linux.git-davehans/init/Kconfig     |  243 ++++++++++++++++++------------------
>  linux.git-davehans/mm/Kconfig.debug |   11 +
>  2 files changed, 135 insertions(+), 119 deletions(-)
> 
> diff -puN init/Kconfig~organize-memory-config-options init/Kconfig
> --- linux.git/init/Kconfig~organize-memory-config-options	2014-01-02 11:24:20.925790194 -0800
> +++ linux.git-davehans/init/Kconfig	2014-01-02 11:24:20.931790464 -0800
> @@ -208,16 +208,6 @@ config DEFAULT_HOSTNAME
>  	  but you may wish to use a different default here to make a minimal
>  	  system more usable with less configuration.
>  
> -config SWAP
> -	bool "Support for paging of anonymous memory (swap)"
> -	depends on MMU && BLOCK
> -	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---
> @@ -760,6 +750,130 @@ endchoice
>  
>  endmenu # "RCU Subsystem"
>  
> +menu "Memory Options"
> +
> +config NUMA_BALANCING
> +	bool "Memory placement aware NUMA scheduler"
> +	depends on ARCH_SUPPORTS_NUMA_BALANCING
> +	depends on !ARCH_WANT_NUMA_VARIABLE_LOCALITY
> +	depends on SMP && NUMA && MIGRATION
> +	help
> +	  This option adds support for automatic NUMA aware memory/task placement.
> +	  The mechanism is quite primitive and is based on migrating memory when
> +	  it has references to the node the task is running on.
> +
> +	  This system will be inactive on UMA systems.
> +
> +config VM_EVENT_COUNTERS
> +	default y
> +	bool "Enable VM event counters for /proc/vmstat" if EXPERT
> +	help
> +	  VM event counters are needed for event counts to be shown.
> +	  This option allows the disabling of the VM event counters
> +	  on EXPERT systems.  /proc/vmstat will only show page counts
> +	  if VM event counters are disabled.
> +
> +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 SWAP
> +	bool "Support for paging of anonymous memory (swap)"
> +	depends on MMU && BLOCK
> +	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"
> +	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)"
> +	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 SLUB_CPU_PARTIAL
> +	default y
> +	depends on SLUB && SMP
> +	bool "SLUB per cpu partial cache"
> +	help
> +	  Per cpu partial caches accellerate 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 SLUB_ATTEMPT_CMPXCHG_DOUBLE
> +	default y
> +	depends on SLUB && HAVE_CMPXCHG_DOUBLE
> +	bool "SLUB: attempt to use double-cmpxchg operations"
> +	help
> +	  Some CPUs support instructions that let you do a large double-word
> +	  atomic cmpxchg operation.  This keeps the SLUB fastpath from
> +	  needing to disable interrupts.
> +
> +	  If you are unsure, say y.
> +
> +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 it's 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/nommu-mmap.txt for more information.
> +
> +endmenu # "Memory Optionse
> +
>  config IKCONFIG
>  	tristate "Kernel .config support"
>  	---help---
> @@ -840,18 +954,6 @@ config NUMA_BALANCING_DEFAULT_ENABLED
>  	  If set, automatic NUMA balancing will be enabled if running on a NUMA
>  	  machine.
>  
> -config NUMA_BALANCING
> -	bool "Memory placement aware NUMA scheduler"
> -	depends on ARCH_SUPPORTS_NUMA_BALANCING
> -	depends on !ARCH_WANT_NUMA_VARIABLE_LOCALITY
> -	depends on SMP && NUMA && MIGRATION
> -	help
> -	  This option adds support for automatic NUMA aware memory/task placement.
> -	  The mechanism is quite primitive and is based on migrating memory when
> -	  it has references to the node the task is running on.
> -
> -	  This system will be inactive on UMA systems.
> -
>  menuconfig CGROUPS
>  	boolean "Control Group support"
>  	depends on EVENTFD
> @@ -1529,103 +1631,6 @@ config DEBUG_PERF_USE_VMALLOC
>  
>  endmenu
>  
> -config VM_EVENT_COUNTERS
> -	default y
> -	bool "Enable VM event counters for /proc/vmstat" if EXPERT
> -	help
> -	  VM event counters are needed for event counts to be shown.
> -	  This option allows the disabling of the VM event counters
> -	  on EXPERT systems.  /proc/vmstat will only show page counts
> -	  if VM event counters are disabled.
> -
> -config SLUB_DEBUG
> -	default y
> -	bool "Enable SLUB debugging support" if EXPERT
> -	depends on SLUB && SYSFS
> -	help
> -	  SLUB has extensive debug support features. Disabling these can
> -	  result in significant savings in code size. This also disables
> -	  SLUB sysfs support. /sys/slab will not exist and there will be
> -	  no support for cache validation etc.
> -
> -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.
> -
> -choice
> -	prompt "Choose SLAB allocator"
> -	default SLUB
> -	help
> -	   This option allows to select a slab allocator.
> -
> -config SLAB
> -	bool "SLAB"
> -	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)"
> -	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 SLUB_CPU_PARTIAL
> -	default y
> -	depends on SLUB && SMP
> -	bool "SLUB per cpu partial cache"
> -	help
> -	  Per cpu partial caches accellerate 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
> -	default n
> -	help
> -	  Normally, and according to the Linux spec, anonymous memory obtained
> -	  from mmap() has it's 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/nommu-mmap.txt for more information.
> -
>  config PROFILING
>  	bool "Profiling support"
>  	help
> diff -puN mm/Kconfig.debug~organize-memory-config-options mm/Kconfig.debug
> --- linux.git/mm/Kconfig.debug~organize-memory-config-options	2014-01-02 11:24:20.927790284 -0800
> +++ linux.git-davehans/mm/Kconfig.debug	2014-01-02 11:24:20.931790464 -0800
> @@ -27,3 +27,14 @@ config PAGE_POISONING
>  config PAGE_GUARD
>  	bool
>  	select WANT_PAGE_DEBUG_FLAGS
> +
> +config SLUB_DEBUG
> +	default y
> +	bool "Enable SLUB debugging support" if EXPERT
> +	depends on SLUB && SYSFS
> +	help
> +	  SLUB has extensive debug support features. Disabling these can
> +	  result in significant savings in code size. This also disables
> +	  SLUB sysfs support. /sys/slab will not exist and there will be
> +	  no support for cache validation etc.
> +
> _
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-02-05 14:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140102202014.CA206E9B@viggo.jf.intel.com>
2014-01-02 20:20 ` [PATCH 3/3] Kconfig: organize memory-related config options Dave Hansen
2014-02-05 14:28   ` Michal Hocko [this message]
2014-02-05 16:27     ` Dave Hansen
     [not found] <20140131172443.2EDC06E7@viggo.jf.intel.com>
2014-01-31 17:24 ` Dave Hansen
2014-02-04 16:02   ` Dave Hansen
2014-02-04 16:14     ` Michal Hocko
2014-02-02  9:50 George Spelvin

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=20140205142820.GD2425@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=dave@sr71.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).