On 11/17/16 at 09:35am, Dave Young wrote:
On 11/16/16 at 04:23pm, 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.
> Signed-off-by: Pratyush Anand <panand(a)redhat.com>
> kdump-lib-initramfs.sh | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
> diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh
> index 4c0e2e2837fd..e1fdb466f741 100755
> --- a/kdump-lib-initramfs.sh
> +++ b/kdump-lib-initramfs.sh
> @@ -21,7 +21,7 @@ NEWROOT="/sysroot"
> - local config_opt config_val
> + local config_opt config_val numcpu
> while read config_opt config_val;
> @@ -73,6 +73,12 @@ get_kdump_confs()
> done < $KDUMP_CONF
> + if [[ "$CORE_COLLECTOR" =~ "makedumpfile" ]]; then
> + if ! [[ $CORE_COLLECTOR =~ "--num-threads" ]]; then
> + numcpu=$(grep -c '^processor' /proc/cpuinfo)
> + CORE_COLLECTOR="$CORE_COLLECTOR --num-threads $numcpu"
> + fi
Since we have the interface for user to change the makedumpfile
arguments so I'm not sure we should do it automaticlly here..
Consider this is for addressing performance regression issue reported by
IBM. Suppose the regression is for 1 cpu only the question is why the
regression happens, using multi threads could only mask the real problem.
Apologize, per discussion in irc, I misunderstood the issue. It is not
for a performance regression report.
> > + fi
> > if [ -z "$CORE_COLLECTOR" ]; then
> > CORE_COLLECTOR="$DEFAULT_CORE_COLLECTOR"
> > if is_ssh_dump_target || is_raw_dump_target; then
> > --
> > 2.7.4