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