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

["Zhou, Wenjian/周文剑"]

On 09/09/2015 05:59 PM, Dave Young wrote:
> 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 at 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.
>

"Notes on" is used in the above of "Parallel Dumping Operation", such as
"Notes on rootfs mount:".

>> +
>> +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?
>

I have just test it. The following is the result.

crashkernel=128M

nr_cpus		1	2	4	8	16
total mem	113372	113212	112972	112492	111532	(KB)
free mem	74360	72648	69760	65128	57032	(KB)

BTW, other comments have been reflected in the new patch.
But I forgot to change the patch version to v2.

-- 
Thanks
Zhou
>> +
>> +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 at lists.fedoraproject.org
>> https://lists.fedoraproject.org/mailman/listinfo/kexec