All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Adrian Bunk <bunk@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] x86: Modify Kconfig to allow up to 4096 cpus
Date: Thu, 27 Mar 2008 08:06:42 -0700	[thread overview]
Message-ID: <47EBB802.7000801@sgi.com> (raw)
In-Reply-To: <20080326165554.GD1789@cs181133002.pp.htv.fi>

Adrian Bunk wrote:
> On Wed, Mar 26, 2008 at 09:31:22AM -0700, Mike Travis wrote:
>> Adrian Bunk wrote:
>>> On Tue, Mar 25, 2008 at 06:41:39PM -0700, Mike Travis wrote:
>>>> Increase the limit of NR_CPUS to 4096 and introduce a boolean
>>>> called "MAXSMP" which when set (e.g. "allyesconfig"), will set
>>>> NR_CPUS = 4096 and NODES_SHIFT = 9 (512).
>>>
>>> I'm not really getting the point of MAXSMP - people should simply pick 
>>> their values, and when they want the maximum "(2-4096)" and "(1-15)" 
>>> already provide this information (except that your patch hides the 
>>> latter information from the user).
>>>
>>> And with your patch, even with MAXSMP=y people could still set 
>>> NR_CPUS=7 and NODES_SHIFT=15 or whatever else they want...
>>>
>>> More interesting would be why you want it to set NODES_SHIFT to 
>>> something less than the maximum value of 15. I'm getting the fact that
>>> 2^15 > 4096 and that 15 might be nonsensical high, but this sounds more 
>>> like requiring a patch to limit the range to 9?
>> I guess the main effect is that "MAXSMP" represents what's really
>> usable for an architecture based on other factors.  The limit of
>> NODES_SHIFT = 15 is that it's represented in some places as a signed
>> 16-bit value, so 15 is the hard limit without coding changes, not
>> an architecture limit.
> 
> 
> This is the x86-specific Kconfig file that presents the x86 specific 
> limits to the users.
> 
> If NODES_SHIFT=15 is offered to the user although it's higher than the 
> current architecture limit on x86 then this is simply a bug that should 
> be fixed.
> 
> 
>> Thanks,
>> Mike
> 
> cu
> Adrian
> 

Ok, I'll modify it in the next version.  

Thanks!
Mike

WARNING: multiple messages have this Message-ID (diff)
From: Mike Travis <travis@sgi.com>
To: Adrian Bunk <bunk@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] x86: Modify Kconfig to allow up to 4096 cpus
Date: Thu, 27 Mar 2008 08:06:42 -0700	[thread overview]
Message-ID: <47EBB802.7000801@sgi.com> (raw)
In-Reply-To: <20080326165554.GD1789@cs181133002.pp.htv.fi>

Adrian Bunk wrote:
> On Wed, Mar 26, 2008 at 09:31:22AM -0700, Mike Travis wrote:
>> Adrian Bunk wrote:
>>> On Tue, Mar 25, 2008 at 06:41:39PM -0700, Mike Travis wrote:
>>>> Increase the limit of NR_CPUS to 4096 and introduce a boolean
>>>> called "MAXSMP" which when set (e.g. "allyesconfig"), will set
>>>> NR_CPUS = 4096 and NODES_SHIFT = 9 (512).
>>>
>>> I'm not really getting the point of MAXSMP - people should simply pick 
>>> their values, and when they want the maximum "(2-4096)" and "(1-15)" 
>>> already provide this information (except that your patch hides the 
>>> latter information from the user).
>>>
>>> And with your patch, even with MAXSMP=y people could still set 
>>> NR_CPUS=7 and NODES_SHIFT=15 or whatever else they want...
>>>
>>> More interesting would be why you want it to set NODES_SHIFT to 
>>> something less than the maximum value of 15. I'm getting the fact that
>>> 2^15 > 4096 and that 15 might be nonsensical high, but this sounds more 
>>> like requiring a patch to limit the range to 9?
>> I guess the main effect is that "MAXSMP" represents what's really
>> usable for an architecture based on other factors.  The limit of
>> NODES_SHIFT = 15 is that it's represented in some places as a signed
>> 16-bit value, so 15 is the hard limit without coding changes, not
>> an architecture limit.
> 
> 
> This is the x86-specific Kconfig file that presents the x86 specific 
> limits to the users.
> 
> If NODES_SHIFT=15 is offered to the user although it's higher than the 
> current architecture limit on x86 then this is simply a bug that should 
> be fixed.
> 
> 
>> Thanks,
>> Mike
> 
> cu
> Adrian
> 

Ok, I'll modify it in the next version.  

Thanks!
Mike

--
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:[~2008-03-27 15:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-26  1:41 [PATCH 0/2] NR_CPUS: increase maximum NR_CPUS to 4096 Mike Travis
2008-03-26  1:41 ` Mike Travis
2008-03-26  1:41 ` [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor Mike Travis
2008-03-26  1:41   ` Mike Travis
2008-03-26  1:41 ` [PATCH 2/2] x86: Modify Kconfig to allow up to 4096 cpus Mike Travis
2008-03-26  1:41   ` Mike Travis
2008-03-26 16:09   ` Adrian Bunk
2008-03-26 16:09     ` Adrian Bunk
2008-03-26 16:31     ` Mike Travis
2008-03-26 16:31       ` Mike Travis
2008-03-26 16:55       ` Adrian Bunk
2008-03-26 16:55         ` Adrian Bunk
2008-03-27 15:06         ` Mike Travis [this message]
2008-03-27 15:06           ` Mike Travis
2008-03-26 19:16       ` Christoph Lameter
2008-03-26 19:16         ` Christoph Lameter
2008-03-26 19:28   ` Yinghai Lu
2008-03-26 19:28     ` Yinghai Lu
2008-03-26  6:19 ` [PATCH 0/2] NR_CPUS: increase maximum NR_CPUS to 4096 Ingo Molnar
2008-03-26  6:19   ` Ingo Molnar
2008-03-26 15:59   ` Mike Travis
2008-03-26 15:59     ` Mike Travis
  -- strict thread matches above, loose matches on Subject: below --
2008-04-05  1:30 Mike Travis
2008-04-05  1:30 ` [PATCH 2/2] x86: Modify Kconfig to allow up to 4096 cpus Mike Travis

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=47EBB802.7000801@sgi.com \
    --to=travis@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --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 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.