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@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 + fi if [ -z "$CORE_COLLECTOR" ]; then CORE_COLLECTOR="$DEFAULT_CORE_COLLECTOR" if is_ssh_dump_target || is_raw_dump_target; then
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..
Thanks Hari
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..
Thanks Hari _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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.
~Pratyush
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..
Thanks Hari
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@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" ]]; thennumcpu=$(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
On 11/17/16 at 09:35am, Dave Young wrote:
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@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" ]]; thennumcpu=$(grep -c '^processor' /proc/cpuinfo)CORE_COLLECTOR="$CORE_COLLECTOR --num-threads $numcpu"fiSince 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
Thanks Dave
On Thursday 17 November 2016 07:05 AM, Dave Young wrote:
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" ]]; thennumcpu=$(grep -c '^processor' /proc/cpuinfo)CORE_COLLECTOR="$CORE_COLLECTOR --num-threads $numcpu"fiSince we have the interface for user to change the makedumpfile arguments so I'm not sure we should do it automaticlly here..
OK..I understood some concern while discussing at IRC, for example with x86 intel cpus, num-threads should be 1 less than the number of oneline cpus for better performance...performance at different filter level can also vary(some time negatively) using num-threads. There can be some other concern as well.
Therefore, I will do some more analysis before I send V2, or may be tuning it manually in kdump.conf would be a better choice, and we do not need any patch. Will come back.
~Pratyush
-
Dave Young -
Hari Bathini -
Pratyush Anand