Hi Pratyush,
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"
get_kdump_confs()
{
- local config_opt config_val
+ local config_opt config_val numcpu
while read config_opt config_val;
do
@@ -73,6 +73,12 @@ get_kdump_confs()
esac
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.
+ fi
if [ -z "$CORE_COLLECTOR" ]; then
CORE_COLLECTOR="$DEFAULT_CORE_COLLECTOR"
if is_ssh_dump_target || is_raw_dump_target; then
--
2.7.4
Thanks
Dave