Add descriptions of parallel dumping and how to use it.
Signed-off-by: Zhou Wenjian zhouwj-fnst@cn.fujitsu.com --- 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
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@cn.fujitsu.com
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
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@cn.fujitsu.com
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.
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@cn.fujitsu.com
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@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
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@cn.fujitsu.com
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.
-
Baoquan He -
Pratyush Anand -
Zhou Wenjian