linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/Kconfig: update "Memory Model" help text
Date: Thu, 25 Apr 2019 14:09:45 +0200	[thread overview]
Message-ID: <20190425120945.GB1144@dhcp22.suse.cz> (raw)
In-Reply-To: <1556188531-20728-1-git-send-email-rppt@linux.ibm.com>

On Thu 25-04-19 13:35:31, Mike Rapoport wrote:
> The help describing the memory model selection is outdated. It still says
> that SPARSEMEM is experimental and DISCONTIGMEM is a preferred over
> SPARSEMEM.
> 
> Update the help text for the relevant options:
> * add a generic help for the "Memory Model" prompt
> * add description for FLATMEM
> * reduce the description of DISCONTIGMEM and add a deprecation note
> * prefer SPARSEMEM over DISCONTIGMEM
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  mm/Kconfig | 48 +++++++++++++++++++++++-------------------------
>  1 file changed, 23 insertions(+), 25 deletions(-)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 25c71eb8a7db..8f7ae4d71b77 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -11,23 +11,24 @@ choice
>  	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 allows you to change some of the ways that
> -	  Linux manages its memory internally.  Most users will
> -	  only have one option here: FLATMEM.  This is normal
> -	  and a correct option.
> -
> -	  Some users of more advanced features like NUMA and
> -	  memory hotplug may have different options here.
> -	  DISCONTIGMEM is a more mature, better tested system,
> -	  but is incompatible with memory hotplug and may suffer
> -	  decreased performance over SPARSEMEM.  If unsure between
> -	  "Sparse Memory" and "Discontiguous Memory", choose
> -	  "Discontiguous Memory".
> +	  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.
>  
> @@ -38,29 +39,26 @@ config DISCONTIGMEM_MANUAL
>  	  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.  However, the vast
> -	  majority of hardware has quite flat address spaces, and
> -	  can have degraded performance from the extra overhead that
> -	  this option imposes.
> +	  more efficient handling of these holes.
>  
> -	  Many NUMA configurations will have this as the only option.
> +	  Although "Discontiguous Memory" is still used by several
> +	  architectures, it is considered deprecated in favor of
> +	  "Sparse Memory".
>  
> -	  If unsure, choose "Flat Memory" over this option.
> +	  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 hotplug systems.  This is normal.
> +	  memory hot-plug systems.  This is normal.
>  
> -	  For many other systems, this will be an alternative to
> -	  "Discontiguous Memory".  This option provides some potential
> -	  performance benefits, along with decreased code complexity,
> -	  but it is newer, and more experimental.
> +	  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 "Discontiguous Memory" or "Flat Memory"
> -	  over this option.
> +	  If unsure, choose "Flat Memory" over this option.
>  
>  endchoice
>  
> -- 
> 2.7.4

-- 
Michal Hocko
SUSE Labs


      reply	other threads:[~2019-04-25 12:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25 10:35 Mike Rapoport
2019-04-25 12:09 ` Michal Hocko [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=20190425120945.GB1144@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@linux.ibm.com \
    /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