On Thursday 17 November 2016 08:57 AM, Pratyush Anand wrote:

On Thursday 17 November 2016 06:59 AM, Dave Young wrote:
On 11/16/16 at 08:31pm, Hari Bathini wrote:
> On Wednesday 16 November 2016 04:23 PM, Pratyush Anand wrote:
> > makedumpfile 1.6.0+ has --num-threads options, where more than one threads
> > can dump the vmcore in parallel. However, number of threads should not be
> > more than usable cpus, otherwise we may have performance degradation.
> >
> > This patch adds --num-threads options by default if core_collector is
> > selected as makedumpfile. It adds number of threads same as the number of
> > online cpus. However, if kdump.conf will have --num-threads specified
> > already then it will not be modified.
> In addition to this patch, how about introducing KDUMP_KERNEL_CPUS=
> in kdump.sysconfig that defaults to some value dynamically, to say 16/8/1
> cpus depending on available cpus, if unset. Alternatively, the user can
> manually
> specify a value of his/her liking. This to be used to pass maxcpus= /
> nr_cpus=
> parameter while loading kdump kernel..
It is risky because more cpus will cause more memory usage, I would
prefer user to specify nr_cpus= in KDUMP_COMMANDLINE_APPEND and only do
that when they have tested it successfully..

..and, moreover IMHO, I do no see much value addition as we will need to change sysconfig/kdump file in both the case.

I understand the apprehension. My point is to have a dynamic default KDUMP_KERNEL_CPUS
value that depends on the cpus in production kernel. Say, a system has just 8 CPUS, we
are better off with nr_cpus/maxcpus set to 1 in that case. But if a system has say 512 CPUS,
then it makes sense to dynamically set the default to say 16.

Effectively, a range based default value like KDUMP_KERNEL_CPUS=1-32:1,32-64:8,64-:16.
Again, arriving at these values needs some number crunching, but it is for the better, I guess.
And of course, a user always has the option to choose otherwise..