Hi,
Some comments inline. I always worry about reviewing documentation patch
because my english is not good enough.
Ccing Pratyush and Vivek, hope any of you can have time to review the
documentation.
On 09/08/15 at 10:22am, Zhou Wenjian wrote:
Add descriptions of parallel dumping and how to use it.
Signed-off-by: Zhou wenjian <zhouwj-fnst(a)cn.fujitsu.com>
Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
---
kexec-kdump-howto.txt | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt
index 05b497f..fab7b09 100644
--- a/kexec-kdump-howto.txt
+++ b/kexec-kdump-howto.txt
@@ -616,6 +616,50 @@ 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 greatly, especially in doing compress and filter.
+For example:
+"makedumpfile -c --num-threads [THREAD_NUM] /proc/vmcore dumpfile"
+has 2 or more times performance of
+"makedumpfile -c /proc/vmcore dumpfile",
+if THREAD_NUM is larger than 2 and the num of cpus that can be used is
s/the num of cpus that can be used/the usable cpu numbers
+larger than THREAD_NUM.
Above paragraph is not easy to undertand, how about drop the example,
we know it can increase performance, but it also depends on test cases?
Such as network trafic in networking dump? So it may have 2 or more times
performance but it is not 100%, right?
+
+Notes on how to use multiple cpus on a capture kernel on x86 system:
I feel "Notes about" is better, but I'm not sure.
+
+To use multiple cpus on a capture kernel on x86 system:
Since there is a line above "Notes on how to.." so "To use" line is
redundant.
+
+- First, confirm that you are using a sufficiently new kernel version
"make sure" is slightly better than "confirm", "sufficiently
new" is not
necessary
+ 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. Thus, you don't need to do anything else except for the
+ confirmation.
Thus, [...] is not necessary.
+
+- Then, you need to specify how many cpus you use in a capture kernel
s/you use/to be used
+ by specifying the number of cpus in nr_cpus kernel option in
+ /etc/sysconfig/kdump. nr_cpus is 1 at default.
+
+Note strongly that you should use necessary and sufficnet amount of
s/sufficnet/sufficient
+cpus on a capture kernel. IOW, don't use too many cpus on a
capture
+kernel, or the capture kernel easily leads to panic due to Out Of
+Memory.
It is a good concern, do you have some test result about the memory
usage for nr_cpus > 1?
+
+There are kernel data structures and drivers allocating memory in
+proportion to the number of cpus. More you use cpus, more and more
+memory system consumes. Memory is rare, limited resource in a capture
+kernel. Reserved memory should be kept as less as possible. When
+configuring nr_cpus option, you should confirm that kdump certainly
+successfully works without leading to panic due to Out Of Memory on a
+capture kernel.
Above paragraph seems is not necessary.
+
+(*) 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.
+
Because disable_cpu_apicid is x86 only, it should be mentioned.
BTW, have anyone tested other arches?
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