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
>> > > can dump the vmcore in parallel. However, number of threads should not
>> > > 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
>> > > 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.