All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Boyer <jwboyer@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	prarit@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: Allow NR_CPUS=1024
Date: Sun, 3 Nov 2013 10:57:30 -0500	[thread overview]
Message-ID: <20131103155729.GB9944@hansolo.jdub.homelinux.org> (raw)
In-Reply-To: <20131103102132.GA6807@gmail.com>

On Sun, Nov 03, 2013 at 11:21:32AM +0100, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@kernel.org> wrote:
> 
> > 
> > * Josh Boyer <jwboyer@redhat.com> wrote:
> > 
> > > The current range for SMP configs is 2 - 512, or a full 4096 in the case 
> > > of MAXSMP.  There are machines that have 1024 CPUs in them today and 
> > > configuring a kernel for that means you are forced to set MAXSMP.  This 
> > > adds additional unnecessary overhead.  While that overhead might be 
> > > considered tiny for large machines, it isn't necessarily so if you are 
> > > building a kernel that runs across a wide variety of machines.  We 
> > > increase the range to 1024 to help with this.
> > >
> > > Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
> > > ---
> > >  arch/x86/Kconfig | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index f67e839..d726b2d 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -825,7 +825,7 @@ config MAXSMP
> > >  config NR_CPUS
> > >  	int "Maximum number of CPUs" if SMP && !MAXSMP
> > >  	range 2 8 if SMP && X86_32 && !X86_BIGSMP
> > > -	range 2 512 if SMP && !MAXSMP
> > > +	range 2 1024 if SMP && !MAXSMP
> > >  	default "1" if !SMP
> > >  	default "4096" if MAXSMP
> > >  	default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000)
> > 
> > Any reason not to allow it to go up to 4096? The original concern was 
> > that CPUS=4096 wasn't working very well and you had to select MAXSMP 
> > deliberately and keep all the pieces.

No real reason to not allow all the way to 4096, no.  I just started
small as I wanted 1024 specifically, and this is the simplest way to
achieve that.

> The other reason was CONFIG_CPUMASK_OFFSTACK: with 4096 CPUs a cpumask is 
> 512 bytes, too large to be kept on the kernel stack.
> 
> MAXSMP forces CONFIG_CPUMASK_OFFSTACK so there's no such concern there.
> 
> With 1024 CPUs a single cpumask is 128 bytes - rather significant as well. 
> With 512 CPUs it's 64 bytes - borderline.
> 
> So I think a better solution would be to allow an increase above 512 CPUs 
> only if CONFIG_CPUMASK_OFFSTACK is also enabled.

OK, that makes sense.  So in this scenario, we could probably either:

a) do away with MAXSMP entirely and just depend on
CONFIG_CPUMASK_OFFSTACK.

b) make MAXSMP something even higher than 4096.  Like 5120 or 6144, etc.

Which would you prefer?  Either is easy enough to code up, I just need
to know which I should shoot for.

josh

  reply	other threads:[~2013-11-03 15:57 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 14:11 [PATCH] x86: Allow NR_CPUS=1024 Josh Boyer
2013-11-03 10:18 ` Ingo Molnar
2013-11-03 10:21   ` Ingo Molnar
2013-11-03 15:57     ` Josh Boyer [this message]
2013-11-03 17:43       ` H. Peter Anvin
2013-11-04  6:51         ` Ingo Molnar
2013-11-04 16:31           ` H. Peter Anvin
2013-11-04  6:53       ` Ingo Molnar
2013-11-04 14:01         ` Josh Boyer
2013-11-04 14:10           ` Ingo Molnar
2013-11-04 14:16             ` Josh Boyer
2013-11-04 14:54               ` Prarit Bhargava
2013-11-04 15:56               ` Russ Anderson
2013-11-04 17:48                 ` Ingo Molnar
2013-11-04 19:08                   ` H. Peter Anvin
2013-11-04 20:11                     ` Ingo Molnar
2013-11-04 22:50                       ` H. Peter Anvin
2013-11-05  6:25                         ` Ingo Molnar
2013-11-05  6:31                           ` Li Zefan
2013-11-03 14:29   ` Prarit Bhargava
2013-11-03 14:42     ` Russ Anderson
2013-11-05 14:37 ` [PATCH 1/2 v2] x86: Allow higher NR_CPUS values Josh Boyer
2013-11-05 14:38   ` [PATCH 2/2] x86: Increase MAXSMP CPU count to 8192 Josh Boyer
2013-11-06  5:56     ` [PATCH v2 " Ingo Molnar
2013-11-06 14:10       ` Josh Boyer
2013-11-06 11:20     ` [tip:x86/cpu] x86/cpu: Increase max " tip-bot for Josh Boyer
2013-11-06  7:15   ` [PATCH 1/2 v2] x86: Allow higher NR_CPUS values Ingo Molnar
2013-11-06 14:12     ` Josh Boyer
2013-11-06 15:04       ` Josh Boyer
2013-11-06 15:21     ` [PATCH v3] x86/cpu: " Josh Boyer
2013-11-07  9:15       ` Ingo Molnar
2013-11-07 13:51         ` Josh Boyer
2013-11-06 11:20   ` [tip:x86/cpu] " tip-bot for Josh Boyer

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=20131103155729.GB9944@hansolo.jdub.homelinux.org \
    --to=jwboyer@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=prarit@redhat.com \
    --cc=tglx@linutronix.de \
    --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.