[PATCH] x86: bump default NR_CPUS for 64-bit configuration

[PATCH] x86: bump default NR_CPUS for 64-bit configuration

[Kirill A. Shutemov]

Default NR_CPUS==8 is not enough to cover high-end desktop
configuration: Haswell-E has upto 16 threads.

Let's increase default NR_CPUS to 64 on 64-bit configuration. With this
value CPU bitmask will still fit into one unsinged long.

Default for 32-bit configuration is still 8: it's unlikely anybody will
run 32-bit kernel on modern hardware.

As alternative we could bump NR_CPUS to 128 to cover all dual-processor
servers with some margin.

For reference: Debian and Suse build their kernels with NR_CPUS==512,
Fedora -- 1024.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6aaf38ac417d..c3333e5be5d7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -851,7 +851,8 @@ config NR_CPUS
 	default "1" if !SMP
 	default "8192" if MAXSMP
 	default "32" if SMP && X86_BIGSMP
-	default "8" if SMP
+	default "8" if SMP && X86_32
+	default "64" if SMP
 	---help---
 	  This allows you to specify the maximum number of CPUs which this
 	  kernel will support.  If CPUMASK_OFFSTACK is enabled, the maximum
-- 
2.1.4

[tip:x86/build] x86/kconfig: Bump default NR_CPUS from 8 to 64 for 64-bit configuration

[tip-bot for Kirill A. Shutemov]

Commit-ID:  c5c19941ad1bb18f010ae47f1db333c00b276d55
Gitweb:     http://git.kernel.org/tip/c5c19941ad1bb18f010ae47f1db333c00b276d55
Author:     Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
AuthorDate: Fri, 8 May 2015 13:25:45 +0300
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 8 May 2015 12:58:56 +0200

x86/kconfig: Bump default NR_CPUS from 8 to 64 for 64-bit configuration

Default NR_CPUS==8 is not enough to cover high-end desktop
configuration: Haswell-E has upto 16 threads.

Let's increase default NR_CPUS to 64 on 64-bit configuration.
With this value CPU bitmask will still fit into one unsigned long.

Default for 32-bit configuration is still 8: it's unlikely
anybody will run 32-bit kernels on modern hardware.

As an alternative we could bump NR_CPUS to 128 to cover all
dual-processor servers with some margin.

For reference: Debian and Suse build their kernels with
NR_CPUS==512, Fedora -- 1024.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1431080745-19792-1-git-send-email-kirill.shutemov@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 226d569..83cd1c7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -851,7 +851,8 @@ config NR_CPUS
 	default "1" if !SMP
 	default "8192" if MAXSMP
 	default "32" if SMP && X86_BIGSMP
-	default "8" if SMP
+	default "8" if SMP && X86_32
+	default "64" if SMP
 	---help---
 	  This allows you to specify the maximum number of CPUs which this
 	  kernel will support.  If CPUMASK_OFFSTACK is enabled, the maximum

Re: [PATCH] x86: bump default NR_CPUS for 64-bit configuration

[Josh Boyer]

On Fri, May 8, 2015 at 6:25 AM, Kirill A. Shutemov
<kirill.shutemov@linux.intel.com> wrote:
> Default NR_CPUS==8 is not enough to cover high-end desktop
> configuration: Haswell-E has upto 16 threads.
>
> Let's increase default NR_CPUS to 64 on 64-bit configuration. With this
> value CPU bitmask will still fit into one unsinged long.
>
> Default for 32-bit configuration is still 8: it's unlikely anybody will
> run 32-bit kernel on modern hardware.
>
> As alternative we could bump NR_CPUS to 128 to cover all dual-processor
> servers with some margin.
>
> For reference: Debian and Suse build their kernels with NR_CPUS==512,
> Fedora -- 1024.

FWIW, we're carrying a patch that drops the "if DEBUG_PER_CPU_MAPS"
dependency for CPUMASK_OFFSTACK to allow us to set that to 1024
without bringing in debug junk.  I sent this patch a long time ago and
Ingo and Linus said it was stupid and it should be auto-selected.
Ingo was going to poke at it IIRC how the thread ended, because I
couldn't see a clean way to make Kconfig do what we wanted.

josh

>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
>  arch/x86/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 6aaf38ac417d..c3333e5be5d7 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -851,7 +851,8 @@ config NR_CPUS
>         default "1" if !SMP
>         default "8192" if MAXSMP
>         default "32" if SMP && X86_BIGSMP
> -       default "8" if SMP
> +       default "8" if SMP && X86_32
> +       default "64" if SMP
>         ---help---
>           This allows you to specify the maximum number of CPUs which this
>           kernel will support.  If CPUMASK_OFFSTACK is enabled, the maximum
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: bump default NR_CPUS for 64-bit configuration

[Ingo Molnar]

* Josh Boyer <jwboyer@fedoraproject.org> wrote:

> On Fri, May 8, 2015 at 6:25 AM, Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com> wrote:
> > Default NR_CPUS==8 is not enough to cover high-end desktop
> > configuration: Haswell-E has upto 16 threads.
> >
> > Let's increase default NR_CPUS to 64 on 64-bit configuration. With this
> > value CPU bitmask will still fit into one unsinged long.
> >
> > Default for 32-bit configuration is still 8: it's unlikely anybody will
> > run 32-bit kernel on modern hardware.
> >
> > As alternative we could bump NR_CPUS to 128 to cover all dual-processor
> > servers with some margin.
> >
> > For reference: Debian and Suse build their kernels with NR_CPUS==512,
> > Fedora -- 1024.
> 
> FWIW, we're carrying a patch that drops the "if DEBUG_PER_CPU_MAPS" 
> dependency for CPUMASK_OFFSTACK to allow us to set that to 1024 
> without bringing in debug junk.  I sent this patch a long time ago 
> and Ingo and Linus said it was stupid and it should be 
> auto-selected. Ingo was going to poke at it IIRC how the thread 
> ended, because I couldn't see a clean way to make Kconfig do what we 
> wanted.

So all that was a long time ago - mind sending a patch so we can 
restart the discussion?

Ideally we'd want 'offstack' be selected automatically by the CPU 
number selection - and I can see how Kconfig might not support 
conditional configs on the scalar value of a Kconfig option.

A workaround would be to remove the primary reliance on the 
configurability of the scalar and bring in a multi-choice option that 
offers sane binary levels for NR_CPUs:

	2
	4
	8
	16
	32
	64
	128
	256
	512
	1024
	2048
	4096
	8192

... with such a scheme the high level interface would then 
automatically select offstack starting at 512 or 1024 CPUs or so.

... plus an EXPERT option that allows the direct setting of the value, 
so that people can set more precise values like 120 CPUs, and maybe 
also allow the separate selection of offstack.

... plus a boot check that emits a printk that suggests the right 
config option if someone boots with a kernel that does not have enough 
CPUs configured - instead of our current vague hints and 'skipped cpu' 
messages in that situation.

It's a bit ugly, but much saner from a user configuration POV IMHO.

I'd also put a comment about the offstack cpumasks dynamic allocation 
overhead cutoff into the help text.

Thanks,

	Ingo