All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Snook <csnook@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [PATCH] change CONFIG_NUMA description
Date: Fri, 07 Nov 2008 17:13:11 -0500	[thread overview]
Message-ID: <4914BD77.2080005@redhat.com> (raw)
In-Reply-To: <20081106085301.GB4890@elte.hu>

Ingo Molnar wrote:
> * KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> 
>> CONFIG_NUMA description talk about a bit old thing.
>> So, following changes are better.
>>
>> o CONFIG_NUMA is no longer EXPERIMENTAL o Opteron is not the only 
>> processor of NUMA topology on x86_64 no longer, but also Intel 
>> Core7i has it.
>>
>> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> ---
>>  arch/x86/Kconfig |    7 +++----
>>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> applied to tip/x86/doc, thanks! I've updated a few other details as 
> well, see the final commit below.
> 
> 	Ingo
> 
> ------------->
> From fd51b2d7d5df932767b89e00d0871a38a2c53e74 Mon Sep 17 00:00:00 2001
> From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Date: Wed, 5 Nov 2008 02:27:19 +0900
> Subject: [PATCH] x86: update CONFIG_NUMA description
> 
> Impact: clarify/update CONFIG_NUMA text
> 
> CONFIG_NUMA description talk about a bit old thing.
> So, following changes are better.
> 
>  o CONFIG_NUMA is no longer EXPERIMENTAL
> 
>  o Opteron is not the only processor of NUMA topology on x86_64 no longer,
>    but also Intel Core7i has it.
> 
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  arch/x86/Kconfig |   16 ++++++++++------
>  1 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 350bee1..38ae04b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -951,22 +951,26 @@ config ARCH_PHYS_ADDR_T_64BIT
>  
>  # Common NUMA Features
>  config NUMA
> -	bool "Numa Memory Allocation and Scheduler Support (EXPERIMENTAL)"
> +	bool "Numa Memory Allocation and Scheduler Support"
>  	depends on SMP
>  	depends on X86_64 || (X86_32 && HIGHMEM64G && (X86_NUMAQ || X86_BIGSMP || X86_SUMMIT && ACPI) && EXPERIMENTAL)
>  	default n if X86_PC
>  	default y if (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP)
>  	help
>  	  Enable NUMA (Non Uniform Memory Access) support.
> +
>  	  The kernel will try to allocate memory used by a CPU on the
>  	  local memory controller of the CPU and add some more
>  	  NUMA awareness to the kernel.
>  
> -	  For 32-bit this is currently highly experimental and should be only
> -	  used for kernel development. It might also cause boot failures.
> -	  For 64-bit this is recommended on all multiprocessor Opteron systems.
> -	  If the system is EM64T, you should say N unless your system is
> -	  EM64T NUMA.
> +	  For 64-bit this is recommended if the system is Intel Core 7i
> +	  (or later), AMD Opteron, or EM64T NUMA.
> +
> +	  For 32-bit this is only needed on (rare) 32-bit-only platforms
> +	  that support NUMA topologies, such as NUMAQ / Summit, or if you
> +	  boot a 32-bit kernel on a 64-bit NUMA platform.
> +
> +	  Otherwise, you should say N.
>  
>  comment "NUMA (Summit) requires SMP, 64GB highmem support, ACPI"
>  	depends on X86_32 && X86_SUMMIT && (!HIGHMEM64G || !ACPI)

Core i7, not Core 7i.

-- Chris

  parent reply	other threads:[~2008-11-07 22:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-04 17:27 [PATCH] change CONFIG_NUMA description KOSAKI Motohiro
2008-11-04 19:36 ` Chris Snook
2008-11-06 22:51   ` Andi Kleen
2008-11-04 20:11 ` Pekka Enberg
2008-11-06  8:53 ` Ingo Molnar
2008-11-06 10:15   ` Pekka Enberg
2008-11-06 10:18     ` KOSAKI Motohiro
2008-11-06 10:22     ` Ingo Molnar
2008-11-07 22:13   ` Chris Snook [this message]
2008-11-08 12:31     ` Ingo Molnar
2008-11-09 11:41     ` KOSAKI Motohiro
2008-11-06 22:50 ` Andi Kleen

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=4914BD77.2080005@redhat.com \
    --to=csnook@redhat.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.