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>
> 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
> command line options using "KDUMP_COMMANDLINE_APPEND=" instead of
> 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
> kexec mailing list