Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932781AbbEMH1s (ORCPT ); Wed, 13 May 2015 03:27:48 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:37696 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753790AbbEMH1q (ORCPT ); Wed, 13 May 2015 03:27:46 -0400 Date: Wed, 13 May 2015 09:27:40 +0200 From: Ingo Molnar To: Josh Boyer Cc: "Kirill A. Shutemov" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86 , "Linux-Kernel@Vger. Kernel. Org" Subject: Re: [PATCH] x86: bump default NR_CPUS for 64-bit configuration Message-ID: <20150513072740.GA17097@gmail.com> References: <1431080745-19792-1-git-send-email-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2659 Lines: 78 * Josh Boyer wrote: > On Fri, May 8, 2015 at 6:25 AM, Kirill A. Shutemov > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/