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
>>> > >
>>> > > 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
>>> > > 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
>> > 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
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
And of course, a user always has the option to choose otherwise..