linux-kernel - Re: [PATCH] x86: bump default NR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 13 May 2015 09:27:40 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Josh Boyer <jwboyer@...oraproject.org>
Cc:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86 <x86@...nel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: bump default NR_CPUS for 64-bit configuration

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

> On Fri, May 8, 2015 at 6:25 AM, Kirill A. Shutemov
> <kirill.shutemov@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/