[PATCH] kexec-kdump-howto:Add introduction of parallel dumping

[Zhou Wenjian]

Add descriptions of parallel dumping and how to use it.

Signed-off-by: Zhou Wenjian <zhouwj-fnst(a)cn.fujitsu.com&gt;
---
 kexec-kdump-howto.txt | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt
index 05b497f..97a319c 100644
--- a/kexec-kdump-howto.txt
+++ b/kexec-kdump-howto.txt
@@ -616,6 +616,38 @@ options are copied from /proc/cmdline. In general it is best to
append
 command line options using "KDUMP_COMMANDLINE_APPEND=" instead of replacing
 the original command line completely.
 
+Parallel Dumping Operation
+==========================
+Kexec allows kdump using multiple cpus. So parallel feature can accelerate
+dumping substantially, especially in executing compress and filter.
+For example:
+
+	1."makedumpfile -c --num-threads [THREAD_NUM] /proc/vmcore dumpfile"
+	2."makedumpfile -c /proc/vmcore dumpfile",
+
+	1 has better performance than 2, if THREAD_NUM is larger than two
+	and the usable cpus number is larger than THREAD_NUM.
+
+Notes on how to use multiple cpus on a capture kernel on x86 system:
+
+Make sure that you are using a sufficiently new kernel version that supports
+disable_cpu_apicid kernel option as a capture kernel, which is needed to
+avoid x86 specific hardware issue (*). The disable_cpu_apicid kernel option
+is automatically appended by kdumpctl script and is ignored if the kernel
+doesn't support it.
+
+You need to specify how many cpus to be used in a capture kernel by specifying
+the number of cpus in nr_cpus kernel option in /etc/sysconfig/kdump. nr_cpus
+is 1 at default.
+
+You should use necessary and suffcient amount of cpus on a capture kernel.
+IOW, don't use too many cpus on a capture kernel, or the capture kernel may
+lead to panic due to Out Of Memory(each cpu uses about 1MB).
+
+(*) Without disable_cpu_apicid kernel option, capture kernel leads to hang,
+system reset or power-off at boot, depending on your system and runtime
+situation at the time of crash.
+
 Debugging Tips
 --------------
 - One can drop into a shell before/after saving vmcore with the help of
-- 
1.8.3.1

[Pratyush Anand]

Hi Zhou,

Thanks for your work.

It seems its a V2. So please prefix with PATCH V2 and resend.

You can use:
git format-patch --subject-prefix="PATCH V2"

On 15/09/2015:10:34:14 AM, Zhou Wenjian wrote:
>  Add descriptions of parallel dumping and how to use it.
>  
>  Signed-off-by: Zhou Wenjian <zhouwj-fnst(a)cn.fujitsu.com&gt;
>  --- 
And since its a single patch so, after you have done format-patch, please write
a change log here as it has been written in 
https://lists.fedoraproject.org/pipermail/kexec/2015-August/002271.html

>   kexec-kdump-howto.txt | 32 ++++++++++++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
>  
>  diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt
>  index 05b497f..97a319c 100644
>  --- a/kexec-kdump-howto.txt
>  +++ b/kexec-kdump-howto.txt
>  @@ -616,6 +616,38 @@ options are copied from /proc/cmdline. In general it is best to
> append
>   command line options using "KDUMP_COMMANDLINE_APPEND=" instead of replacing
>   the original command line completely.
>   
>  +Parallel Dumping Operation
>  +==========================
>  +Kexec allows kdump using multiple cpus. So parallel feature can accelerate
>  +dumping substantially, especially in executing compress and filter.
>  +For example:
>  +
>  +	1."makedumpfile -c --num-threads [THREAD_NUM] /proc/vmcore dumpfile"
>  +	2."makedumpfile -c /proc/vmcore dumpfile",
>  +
>  +	1 has better performance than 2, if THREAD_NUM is larger than two
>  +	and the usable cpus number is larger than THREAD_NUM.
>  +
>  +Notes on how to use multiple cpus on a capture kernel on x86 system:
>  +
>  +Make sure that you are using a sufficiently new kernel version that supports 
I remember Dave suggested to avoid "sufficiently new". So, if you do not agree
with some comment then please let that know, otherwise reviewer will assume that
you agreed.

>  +disable_cpu_apicid kernel option as a capture kernel, which is
> needed to
>  +avoid x86 specific hardware issue (*). The disable_cpu_apicid kernel option
>  +is automatically appended by kdumpctl script and is ignored if the kernel
>  +doesn't support it.
>  +
>  +You need to specify how many cpus to be used in a capture kernel by specifying
>  +the number of cpus in nr_cpus kernel option in /etc/sysconfig/kdump. nr_cpus
>  +is 1 at default.
>  +
>  +You should use necessary and suffcient amount of cpus on a capture kernel. 
I still think that "number of cpus" would have been a better choice than
"amount
of cpus".

Other than above two minor thing, patch looks fine to me.

~Pratyush

[Zhou Wenjian]

Hello,

Thanks for reviewing. I will resend the v2 patch.

On 09/16/2015 02:20 PM, Pratyush Anand wrote:
>  Hi Zhou,
>
>  Thanks for your work.
>
>  It seems its a V2. So please prefix with PATCH V2 and resend.
>
>  You can use:
>  git format-patch --subject-prefix="PATCH V2"
>  
I see.

>  On 15/09/2015:10:34:14 AM, Zhou Wenjian wrote:
> > Add descriptions of parallel dumping and how to use it.
> >
> > Signed-off-by: Zhou Wenjian <zhouwj-fnst(a)cn.fujitsu.com&gt;
> > ---
>
>  And since its a single patch so, after you have done format-patch, please write
>  a change log here as it has been written in
>  https://lists.fedoraproject.org/pipermail/kexec/2015-August/002271.html
>  
I see.

> >   kexec-kdump-howto.txt | 32 ++++++++++++++++++++++++++++++++
> >   1 file changed, 32 insertions(+)
> >
> > diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt
> > index 05b497f..97a319c 100644
> > --- a/kexec-kdump-howto.txt
> > +++ b/kexec-kdump-howto.txt
> > @@ -616,6 +616,38 @@ options are copied from /proc/cmdline. In general it is best to
> append
> >   command line options using "KDUMP_COMMANDLINE_APPEND=" instead of
> replacing
> >   the original command line completely.
> >
> > +Parallel Dumping Operation
> > +==========================
> > +Kexec allows kdump using multiple cpus. So parallel feature can accelerate
> > +dumping substantially, especially in executing compress and filter.
> > +For example:
> > +
> > +	1."makedumpfile -c --num-threads [THREAD_NUM] /proc/vmcore dumpfile"
> > +	2."makedumpfile -c /proc/vmcore dumpfile",
> > +
> > +	1 has better performance than 2, if THREAD_NUM is larger than two
> > +	and the usable cpus number is larger than THREAD_NUM.
> > +
> > +Notes on how to use multiple cpus on a capture kernel on x86 system:
> > +
> > +Make sure that you are using a sufficiently new kernel version that supports
>
>  I remember Dave suggested to avoid "sufficiently new". So, if you do not agree
>  with some comment then please let that know, otherwise reviewer will assume that
>  you agreed.
>  
Sorry, I haven't noticed that.

> > +disable_cpu_apicid kernel option as a capture kernel, which is
> needed to
> > +avoid x86 specific hardware issue (*). The disable_cpu_apicid kernel option
> > +is automatically appended by kdumpctl script and is ignored if the kernel
> > +doesn't support it.
> > +
> > +You need to specify how many cpus to be used in a capture kernel by specifying
> > +the number of cpus in nr_cpus kernel option in /etc/sysconfig/kdump. nr_cpus
> > +is 1 at default.
> > +
> > +You should use necessary and suffcient amount of cpus on a capture kernel.
>
>  I still think that "number of cpus" would have been a better choice than
> "amount
>  of cpus".
>  
I see.

-- 
Thanks
Zhou

>  Other than above two minor thing, patch looks fine to me.
>
>  ~Pratyush
>

[Baoquan He]

On 09/15/15 at 10:34am, Zhou Wenjian wrote:
>  Add descriptions of parallel dumping and how to use it.
>  
>  Signed-off-by: Zhou Wenjian <zhouwj-fnst(a)cn.fujitsu.com&gt;
>  ---
>   kexec-kdump-howto.txt | 32 ++++++++++++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
>  
>  diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt
>  index 05b497f..97a319c 100644
>  --- a/kexec-kdump-howto.txt
>  +++ b/kexec-kdump-howto.txt
>  @@ -616,6 +616,38 @@ options are copied from /proc/cmdline. In general it is best to
> append
>   command line options using "KDUMP_COMMANDLINE_APPEND=" instead of replacing
>   the original command line completely.
>   
>  +Parallel Dumping Operation
>  +==========================
>  +Kexec allows kdump using multiple cpus. So parallel feature can accelerate
>  +dumping substantially, especially in executing compress and filter.
>  +For example:
>  +
>  +	1."makedumpfile -c --num-threads [THREAD_NUM] /proc/vmcore dumpfile"
>  +	2."makedumpfile -c /proc/vmcore dumpfile",
>  +
>  +	1 has better performance than 2, if THREAD_NUM is larger than two
>  +	and the usable cpus number is larger than THREAD_NUM.
>  +
>  +Notes on how to use multiple cpus on a capture kernel on x86 system:
>  +
>  +Make sure that you are using a sufficiently new kernel version that supports
>  +disable_cpu_apicid kernel option as a capture kernel, which is needed to
>  +avoid x86 specific hardware issue (*). The disable_cpu_apicid kernel option
>  +is automatically appended by kdumpctl script and is ignored if the kernel
>  +doesn't support it.
>  +
>  +You need to specify how many cpus to be used in a capture kernel by specifying
>  +the number of cpus in nr_cpus kernel option in /etc/sysconfig/kdump. nr_cpus
>  +is 1 at default.
>  +
>  +You should use necessary and suffcient amount of cpus on a capture kernel.
>  +IOW, don't use too many cpus on a capture kernel, or the capture kernel may
>  +lead to panic due to Out Of Memory(each cpu uses about 1MB).
>  +
>  +(*) Without disable_cpu_apicid kernel option, capture kernel leads to hang,
>  +system reset or power-off at boot, depending on your system and runtime
>  +situation at the time of crash. 
Without disable_cpu_apicid, it doesn't necessarily lead to those above
hehaviour. As I remember when crash happened on boot cpu of first kernel
capture kernel can work well with all CPUs up. If and only if crash is
triggered on non-boot cpu of first kernel, it will lead to behaviours
you mentioned. So I suggest here you should use "capture kernel may lead
to hang, xxxxx" instead.

>  +
>   Debugging Tips
>   --------------
>   - One can drop into a shell before/after saving vmcore with the help of
>  -- 
>  1.8.3.1
>  
>  _______________________________________________
>  kexec mailing list
>  kexec(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/mailman/listinfo/kexec

[Zhou Wenjian]

On 09/16/2015 03:08 PM, Baoquan He wrote:
>  On 09/15/15 at 10:34am, Zhou Wenjian wrote:
> > Add descriptions of parallel dumping and how to use it.
> >
> > Signed-off-by: Zhou Wenjian <zhouwj-fnst(a)cn.fujitsu.com&gt;
> > ---
> >   kexec-kdump-howto.txt | 32 ++++++++++++++++++++++++++++++++
> >   1 file changed, 32 insertions(+)
> >
> > diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt
> > index 05b497f..97a319c 100644
> > --- a/kexec-kdump-howto.txt
> > +++ b/kexec-kdump-howto.txt
> > @@ -616,6 +616,38 @@ options are copied from /proc/cmdline. In general it is best to
> append
> >   command line options using "KDUMP_COMMANDLINE_APPEND=" instead of
> replacing
> >   the original command line completely.
> >
> > +Parallel Dumping Operation
> > +==========================
> > +Kexec allows kdump using multiple cpus. So parallel feature can accelerate
> > +dumping substantially, especially in executing compress and filter.
> > +For example:
> > +
> > +	1."makedumpfile -c --num-threads [THREAD_NUM] /proc/vmcore dumpfile"
> > +	2."makedumpfile -c /proc/vmcore dumpfile",
> > +
> > +	1 has better performance than 2, if THREAD_NUM is larger than two
> > +	and the usable cpus number is larger than THREAD_NUM.
> > +
> > +Notes on how to use multiple cpus on a capture kernel on x86 system:
> > +
> > +Make sure that you are using a sufficiently new kernel version that supports
> > +disable_cpu_apicid kernel option as a capture kernel, which is needed to
> > +avoid x86 specific hardware issue (*). The disable_cpu_apicid kernel option
> > +is automatically appended by kdumpctl script and is ignored if the kernel
> > +doesn't support it.
> > +
> > +You need to specify how many cpus to be used in a capture kernel by specifying
> > +the number of cpus in nr_cpus kernel option in /etc/sysconfig/kdump. nr_cpus
> > +is 1 at default.
> > +
> > +You should use necessary and suffcient amount of cpus on a capture kernel.
> > +IOW, don't use too many cpus on a capture kernel, or the capture kernel may
> > +lead to panic due to Out Of Memory(each cpu uses about 1MB).
> > +
> > +(*) Without disable_cpu_apicid kernel option, capture kernel leads to hang,
> > +system reset or power-off at boot, depending on your system and runtime
> > +situation at the time of crash.
>
>  Without disable_cpu_apicid, it doesn't necessarily lead to those above
>  hehaviour. As I remember when crash happened on boot cpu of first kernel
>  capture kernel can work well with all CPUs up. If and only if crash is
>  triggered on non-boot cpu of first kernel, it will lead to behaviours
>  you mentioned. So I suggest here you should use "capture kernel may lead
>  to hang, xxxxx" instead.
>  
I see.

-- 
Thanks
Zhou

> > +
> >   Debugging Tips
> >   --------------
> >   - One can drop into a shell before/after saving vmcore with the help of
> > --
> > 1.8.3.1
> >
> > _______________________________________________
> > kexec mailing list
> > kexec(a)lists.fedoraproject.org
> > https://lists.fedoraproject.org/mailman/listinfo/kexec