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 <[email protected]>
---
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
Commit-ID: c5c19941ad1bb18f010ae47f1db333c00b276d55
Gitweb: http://git.kernel.org/tip/c5c19941ad1bb18f010ae47f1db333c00b276d55
Author: Kirill A. Shutemov <[email protected]>
AuthorDate: Fri, 8 May 2015 13:25:45 +0300
Committer: Ingo Molnar <[email protected]>
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 <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/1431080745-19792-1-git-send-email-kirill.shutemov@linux.intel.com
Signed-off-by: Ingo Molnar <[email protected]>
---
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
On Fri, May 8, 2015 at 6:25 AM, Kirill A. Shutemov
<[email protected]> 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 <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
* Josh Boyer <[email protected]> wrote:
> On Fri, May 8, 2015 at 6:25 AM, Kirill A. Shutemov
> <[email protected]> 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