A new feature that doing compressing and writing by multi-threads has been added in makedumpfile. The thread num is specified by "--num-threads NUM". According to its implementation, there will be performance degradation if the threads are more than cpus. So we should check it.
Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com --- kdumpctl | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kdumpctl b/kdumpctl index b504734..fd2abe4 100755 --- a/kdumpctl +++ b/kdumpctl @@ -259,6 +259,21 @@ check_config() esac done < $KDUMP_CONFIG_FILE
+ grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads" + if [ $? -eq 0 ];then + local nr_cpus=1 + local num_threads=0 + local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE` + + num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'` + nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'` + + if [ $num_threads -ge $nr_cpus ];then + echo "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)" + echo "or makedumpfile may have bad performance!" + fi + fi + check_fence_kdump_config || return 1
return 0
Hi. Wenjian.
Thougt deeply about this patch, I have following concerns.
Without this patch, do you have any testing about the performance degradation, if num_threads is larger than real cpu number?
Is it proper to do the checking in kdumpctl, since kdump takes more care of setuping 2nd kernel, not the blendings of makedumpfile.
Thanks Minfei
On 08/25/15 at 04:43pm, Zhou Wenjian wrote:
A new feature that doing compressing and writing by multi-threads has been added in makedumpfile. The thread num is specified by "--num-threads NUM". According to its implementation, there will be performance degradation if the threads are more than cpus. So we should check it.
Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com
kdumpctl | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kdumpctl b/kdumpctl index b504734..fd2abe4 100755 --- a/kdumpctl +++ b/kdumpctl @@ -259,6 +259,21 @@ check_config() esac done < $KDUMP_CONFIG_FILE
grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads"
if [ $? -eq 0 ];then
local nr_cpus=1local num_threads=0local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE`num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'`nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'`if [ $num_threads -ge $nr_cpus ];thenecho "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)"echo "or makedumpfile may have bad performance!"fifi
check_fence_kdump_config || return 1
return 0
-- 1.7.1
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 08/25/2015 07:44 PM, Minfei Huang wrote:
Hi. Wenjian.
Thougt deeply about this patch, I have following concerns.
Without this patch, do you have any testing about the performance degradation, if num_threads is larger than real cpu number?
Yes, of course. I can show you some test results.
without num-threads: 9.5s num-threads 2: 6.2s num-threads 3: 56.7s num-threads 4: 3m23s num-threads 5: 3m43s num-threads 6: 4m51s
Is it proper to do the checking in kdumpctl, since kdump takes more care of setuping 2nd kernel, not the blendings of makedumpfile.
I think there is no problem. It's not only the setting of makedumpfile, but also the setting of KDUMP_COMMANDLINE_APPEND.
And it is surely that it can't be done by makedumpfile.
Hi,
On 08/25/15 at 04:43pm, Zhou Wenjian wrote:
A new feature that doing compressing and writing by multi-threads has been added in makedumpfile. The thread num is specified by "--num-threads NUM". According to its implementation, there will be performance degradation if the threads are more than cpus. So we should check it.
Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com
kdumpctl | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kdumpctl b/kdumpctl index b504734..fd2abe4 100755 --- a/kdumpctl +++ b/kdumpctl @@ -259,6 +259,21 @@ check_config() esac done < $KDUMP_CONFIG_FILE
- grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads"
- if [ $? -eq 0 ];then
local nr_cpus=1local num_threads=0local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE`num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'`nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'`if [ $num_threads -ge $nr_cpus ];thenecho "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)"echo "or makedumpfile may have bad performance!"
It is better to do this in makedumpfile source code instead of adding these warnings specific for num-threads here.
fifi
check_fence_kdump_config || return 1
return 0
-- 1.7.1
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
Hello Dave,
On 08/26/2015 03:59 PM, Dave Young wrote:
Hi,
On 08/25/15 at 04:43pm, Zhou Wenjian wrote:
A new feature that doing compressing and writing by multi-threads has been added in makedumpfile. The thread num is specified by "--num-threads NUM". According to its implementation, there will be performance degradation if the threads are more than cpus. So we should check it.
Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com
kdumpctl | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kdumpctl b/kdumpctl index b504734..fd2abe4 100755 --- a/kdumpctl +++ b/kdumpctl @@ -259,6 +259,21 @@ check_config() esac done < $KDUMP_CONFIG_FILE
- grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads"
- if [ $? -eq 0 ];then
local nr_cpus=1local num_threads=0local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE`num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'`nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'`if [ $num_threads -ge $nr_cpus ];thenecho "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)"echo "or makedumpfile may have bad performance!"It is better to do this in makedumpfile source code instead of adding these warnings specific for num-threads here.
I have one more question. Since multi-thread feature is associated with nr_cpus, should we do something here?
On 08/26/15 at 04:18pm, "Zhou, Wenjian/周文剑" wrote:
Hello Dave,
On 08/26/2015 03:59 PM, Dave Young wrote:
Hi,
On 08/25/15 at 04:43pm, Zhou Wenjian wrote:
A new feature that doing compressing and writing by multi-threads has been added in makedumpfile. The thread num is specified by "--num-threads NUM". According to its implementation, there will be performance degradation if the threads are more than cpus. So we should check it.
Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com
kdumpctl | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kdumpctl b/kdumpctl index b504734..fd2abe4 100755 --- a/kdumpctl +++ b/kdumpctl @@ -259,6 +259,21 @@ check_config() esac done < $KDUMP_CONFIG_FILE
- grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads"
- if [ $? -eq 0 ];then
local nr_cpus=1local num_threads=0local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE`num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'`nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'`if [ $num_threads -ge $nr_cpus ];thenecho "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)"echo "or makedumpfile may have bad performance!"It is better to do this in makedumpfile source code instead of adding these warnings specific for num-threads here.
I have one more question. Since multi-thread feature is associated with nr_cpus, should we do something here?
Hmm, adding it in makedumpfile will be too late for warning users. But I do not like adding these stuff in distribution script, user should know the limitation if he choose the thread number. How about moving it to makedumpfile --help to describe the problem just around the num_threads option.
-- Thanks Zhou
fifi
check_fence_kdump_config || return 1
return 0
-- 1.7.1
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 08/26/2015 04:26 PM, Dave Young wrote:
On 08/26/15 at 04:18pm, "Zhou, Wenjian/周文剑" wrote:
Hello Dave,
On 08/26/2015 03:59 PM, Dave Young wrote:
Hi,
On 08/25/15 at 04:43pm, Zhou Wenjian wrote:
A new feature that doing compressing and writing by multi-threads has been added in makedumpfile. The thread num is specified by "--num-threads NUM". According to its implementation, there will be performance degradation if the threads are more than cpus. So we should check it.
Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com
kdumpctl | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kdumpctl b/kdumpctl index b504734..fd2abe4 100755 --- a/kdumpctl +++ b/kdumpctl @@ -259,6 +259,21 @@ check_config() esac done < $KDUMP_CONFIG_FILE
- grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads"
- if [ $? -eq 0 ];then
local nr_cpus=1local num_threads=0local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE`num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'`nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'`if [ $num_threads -ge $nr_cpus ];thenecho "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)"echo "or makedumpfile may have bad performance!"It is better to do this in makedumpfile source code instead of adding these warnings specific for num-threads here.
I have one more question. Since multi-thread feature is associated with nr_cpus, should we do something here?
Hmm, adding it in makedumpfile will be too late for warning users. But I do not like adding these stuff in distribution script, user should know the limitation if he choose the thread number. How about moving it to makedumpfile --help to describe the problem just around the num_threads option.
Whatever, we should not introduce nr_cpus in makedumpfile --help. I noticed a discussion between Vivek and Hatayama. (You can refer to https://lists.fedoraproject.org/pipermail/kexec/2014-March/000687.html) I think finishing that patch may help. I will post the patch later. Please give me some comments on the later patch.
On 09/08/15 at 10:21am, "Zhou, Wenjian/周文剑" wrote:
On 08/26/2015 04:26 PM, Dave Young wrote:
On 08/26/15 at 04:18pm, "Zhou, Wenjian/周文剑" wrote:
Hello Dave,
On 08/26/2015 03:59 PM, Dave Young wrote:
Hi,
On 08/25/15 at 04:43pm, Zhou Wenjian wrote:
A new feature that doing compressing and writing by multi-threads has been added in makedumpfile. The thread num is specified by "--num-threads NUM". According to its implementation, there will be performance degradation if the threads are more than cpus. So we should check it.
Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com
kdumpctl | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kdumpctl b/kdumpctl index b504734..fd2abe4 100755 --- a/kdumpctl +++ b/kdumpctl @@ -259,6 +259,21 @@ check_config() esac done < $KDUMP_CONFIG_FILE
- grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads"
- if [ $? -eq 0 ];then
local nr_cpus=1local num_threads=0local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE`num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'`nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'`if [ $num_threads -ge $nr_cpus ];thenecho "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)"echo "or makedumpfile may have bad performance!"It is better to do this in makedumpfile source code instead of adding these warnings specific for num-threads here.
I have one more question. Since multi-thread feature is associated with nr_cpus, should we do something here?
Hmm, adding it in makedumpfile will be too late for warning users. But I do not like adding these stuff in distribution script, user should know the limitation if he choose the thread number. How about moving it to makedumpfile --help to describe the problem just around the num_threads option.
Whatever, we should not introduce nr_cpus in makedumpfile --help. I noticed a discussion between Vivek and Hatayama. (You can refer to https://lists.fedoraproject.org/pipermail/kexec/2014-March/000687.html) I think finishing that patch may help. I will post the patch later. Please give me some comments on the later patch.
I'm fine to add something in kexec kdump howto document, it is better than adding more logic in kdumpctl.
Why do you think it is bad to add it to makedumpfile? Maybe makedumpfile manpage?
Thanks Dave
On 09/08/2015 03:15 PM, Dave Young wrote:
On 09/08/15 at 10:21am, "Zhou, Wenjian/周文剑" wrote:
On 08/26/2015 04:26 PM, Dave Young wrote:
On 08/26/15 at 04:18pm, "Zhou, Wenjian/周文剑" wrote:
Hello Dave,
On 08/26/2015 03:59 PM, Dave Young wrote:
Hi,
On 08/25/15 at 04:43pm, Zhou Wenjian wrote:
A new feature that doing compressing and writing by multi-threads has been added in makedumpfile. The thread num is specified by "--num-threads NUM". According to its implementation, there will be performance degradation if the threads are more than cpus. So we should check it.
Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com
kdumpctl | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kdumpctl b/kdumpctl index b504734..fd2abe4 100755 --- a/kdumpctl +++ b/kdumpctl @@ -259,6 +259,21 @@ check_config() esac done < $KDUMP_CONFIG_FILE
- grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads"
- if [ $? -eq 0 ];then
local nr_cpus=1local num_threads=0local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE`num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'`nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'`if [ $num_threads -ge $nr_cpus ];thenecho "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)"echo "or makedumpfile may have bad performance!"It is better to do this in makedumpfile source code instead of adding these warnings specific for num-threads here.
I have one more question. Since multi-thread feature is associated with nr_cpus, should we do something here?
Hmm, adding it in makedumpfile will be too late for warning users. But I do not like adding these stuff in distribution script, user should know the limitation if he choose the thread number. How about moving it to makedumpfile --help to describe the problem just around the num_threads option.
Whatever, we should not introduce nr_cpus in makedumpfile --help. I noticed a discussion between Vivek and Hatayama. (You can refer to https://lists.fedoraproject.org/pipermail/kexec/2014-March/000687.html) I think finishing that patch may help. I will post the patch later. Please give me some comments on the later patch.
I'm fine to add something in kexec kdump howto document, it is better than adding more logic in kdumpctl.
Why do you think it is bad to add it to makedumpfile? Maybe makedumpfile manpage?
I just think it's not good to add the description of setting nr_cpus to makedumpfile.
As I mentioned in another thread: In kexec, we should tell users how to bring up multiple cpus and what the benefit is. In makedumpfiel, we should tell users how to use multiple threads and what may affect the performance.
What do you think about Minfei's idea that adding an option to turn on/off parallel dumping?
I think just telling user how to use is more suitable.
On 09/08/15 at 03:32pm, "Zhou, Wenjian/周文剑" wrote:
On 09/08/2015 03:15 PM, Dave Young wrote:
On 09/08/15 at 10:21am, "Zhou, Wenjian/周文剑" wrote:
On 08/26/2015 04:26 PM, Dave Young wrote:
On 08/26/15 at 04:18pm, "Zhou, Wenjian/周文剑" wrote:
Hello Dave,
On 08/26/2015 03:59 PM, Dave Young wrote:
Hi,
On 08/25/15 at 04:43pm, Zhou Wenjian wrote: >A new feature that doing compressing and writing by multi-threads >has been added in makedumpfile. The thread num is specified by >"--num-threads NUM". According to its implementation, there will >be performance degradation if the threads are more than cpus. >So we should check it. > >Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com >--- > kdumpctl | 15 +++++++++++++++ > 1 files changed, 15 insertions(+), 0 deletions(-) > >diff --git a/kdumpctl b/kdumpctl >index b504734..fd2abe4 100755 >--- a/kdumpctl >+++ b/kdumpctl >@@ -259,6 +259,21 @@ check_config() > esac > done < $KDUMP_CONFIG_FILE > >+ grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads" >+ if [ $? -eq 0 ];then >+ local nr_cpus=1 >+ local num_threads=0 >+ local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE` >+ >+ num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'` >+ nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'` >+ >+ if [ $num_threads -ge $nr_cpus ];then >+ echo "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)" >+ echo "or makedumpfile may have bad performance!"
It is better to do this in makedumpfile source code instead of adding these warnings specific for num-threads here.
I have one more question. Since multi-thread feature is associated with nr_cpus, should we do something here?
Hmm, adding it in makedumpfile will be too late for warning users. But I do not like adding these stuff in distribution script, user should know the limitation if he choose the thread number. How about moving it to makedumpfile --help to describe the problem just around the num_threads option.
Whatever, we should not introduce nr_cpus in makedumpfile --help. I noticed a discussion between Vivek and Hatayama. (You can refer to https://lists.fedoraproject.org/pipermail/kexec/2014-March/000687.html) I think finishing that patch may help. I will post the patch later. Please give me some comments on the later patch.
I'm fine to add something in kexec kdump howto document, it is better than adding more logic in kdumpctl.
Why do you think it is bad to add it to makedumpfile? Maybe makedumpfile manpage?
I just think it's not good to add the description of setting nr_cpus to makedumpfile.
As I mentioned in another thread: In kexec, we should tell users how to bring up multiple cpus and what the benefit is. In makedumpfiel, we should tell users how to use multiple threads and what may affect the performance.
What do you think about Minfei's idea that adding an option to turn on/off parallel dumping?
I think an option to turn on and off is reasonable, but one more option to set num_threads is also necessary if someone want to customize it.
Suppose --num-threads is provided it will be used, if there's no --num-threads and the switch option is on then makedumpfile can check cpu number and select proper threads number.
Thanks Dave
On 09/08/2015 04:56 PM, Dave Young wrote:
On 09/08/15 at 03:32pm, "Zhou, Wenjian/周文剑" wrote:
On 09/08/2015 03:15 PM, Dave Young wrote:
On 09/08/15 at 10:21am, "Zhou, Wenjian/周文剑" wrote:
On 08/26/2015 04:26 PM, Dave Young wrote:
On 08/26/15 at 04:18pm, "Zhou, Wenjian/周文剑" wrote:
Hello Dave,
On 08/26/2015 03:59 PM, Dave Young wrote: > Hi, > > On 08/25/15 at 04:43pm, Zhou Wenjian wrote: >> A new feature that doing compressing and writing by multi-threads >> has been added in makedumpfile. The thread num is specified by >> "--num-threads NUM". According to its implementation, there will >> be performance degradation if the threads are more than cpus. >> So we should check it. >> >> Signed-off-by: Zhou wenjian zhouwj-fnst@cn.fujitsu.com >> --- >> kdumpctl | 15 +++++++++++++++ >> 1 files changed, 15 insertions(+), 0 deletions(-) >> >> diff --git a/kdumpctl b/kdumpctl >> index b504734..fd2abe4 100755 >> --- a/kdumpctl >> +++ b/kdumpctl >> @@ -259,6 +259,21 @@ check_config() >> esac >> done < $KDUMP_CONFIG_FILE >> >> + grep "^core_collector.*makedumpfile" $KDUMP_CONFIG_FILE | grep -q "num-threads" >> + if [ $? -eq 0 ];then >> + local nr_cpus=1 >> + local num_threads=0 >> + local core_collector=`grep "^core_collector" $KDUMP_CONFIG_FILE` >> + >> + num_threads=`echo ${core_collector#*--num-threads} | awk '{print $1}'` >> + nr_cpus=`echo ${KDUMP_COMMANDLINE_APPEND#*nr_cpus=} | awk '{print $1}'` >> + >> + if [ $num_threads -ge $nr_cpus ];then >> + echo "The num_threads:$num_threads(specified in /etc/kdump.conf) should be less than nr_cpus:$nr_cpus(specified in /etc/sysconfig/kdump)" >> + echo "or makedumpfile may have bad performance!" > > It is better to do this in makedumpfile source code instead of adding > these warnings specific for num-threads here. >
I have one more question. Since multi-thread feature is associated with nr_cpus, should we do something here?
Hmm, adding it in makedumpfile will be too late for warning users. But I do not like adding these stuff in distribution script, user should know the limitation if he choose the thread number. How about moving it to makedumpfile --help to describe the problem just around the num_threads option.
Whatever, we should not introduce nr_cpus in makedumpfile --help. I noticed a discussion between Vivek and Hatayama. (You can refer to https://lists.fedoraproject.org/pipermail/kexec/2014-March/000687.html) I think finishing that patch may help. I will post the patch later. Please give me some comments on the later patch.
I'm fine to add something in kexec kdump howto document, it is better than adding more logic in kdumpctl.
Why do you think it is bad to add it to makedumpfile? Maybe makedumpfile manpage?
I just think it's not good to add the description of setting nr_cpus to makedumpfile.
As I mentioned in another thread: In kexec, we should tell users how to bring up multiple cpus and what the benefit is. In makedumpfiel, we should tell users how to use multiple threads and what may affect the performance.
What do you think about Minfei's idea that adding an option to turn on/off parallel dumping?
I think an option to turn on and off is reasonable, but one more option to set num_threads is also necessary if someone want to customize it.
Suppose --num-threads is provided it will be used, if there's no --num-threads and the switch option is on then makedumpfile can check cpu number and select proper threads number.
Using more cpus won't always has better performance. From this point of view, turn on or off has no differences.
I think this topic is more suitable in makedumpfile's mailing list.
How about the patch of kexec kdump howto document ?
-
Dave Young -
Minfei Huang -
Zhou Wenjian