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

["Zhou, Wenjian/周文剑"]

On 09/08/2015 02:37 PM, Minfei Huang wrote:
> On 09/08/15 at 01:57pm, "Zhou, Wenjian/周文剑" wrote:
>> Hello Minfei,
>>
>> I get what you mean now.
>> You mean adding an option that user can choose whether using
>> parallel feature or not and if parallel feature is used, than
>> setting the default value of num_threads according to the
>> nr_cpus, right?
>>
>
> Yes.
>
>> I think there are two questions.
>> One is that the option is only for makedumpfile, and it even
>> focus on makedumpfile's arguments. It's not a good idea to do
>> so much work for makedumpfile in kexec.
>>
>
> Yes, makedumpfile will add a new argument to enable/disable the parallel
> thread feature. As I talked in previous thread, system may only enable
> nr_cpus - 1 CPUs in 2nd kernel, due to intel CPU bug.
>
> Following is the performance testing you pasted:
>      without num-threads: 9.5s
>      num-threads 2:       6.2s
>      num-threads 3:       56.7s
>      num-threads 4:       3m23s
>      num-threads 5:       3m43s
>      num-threads 6:       4m51s
>
> Thus the parallel thread feature may casue the bad performance.
>
>> The other is that if user set the num_threads value by their
>> selves, and the value is larger than the cpus,  it can't do
>> any help.
>>
>
> What I talked in previous thread is that we can not specify the number
> of threads in kdump.conf. Only we can do is to enable/disable parallel
> thread feature (makedumpfile will create the number of thread according
> to the running CPU in 2nd kernel).
>

Using too more cpus won't always have better performance. Since num_threads
is introduced to improve the performance, setting default num_threads value
has little meaning. User should know the parallel feature well, or he will
have been satisfied without multiple threads.

And even parallel thread feature is enabled, if the value nr_cpus
is 1, parallel thread won't work. It may be very strange to users.

But whatever, it's needed to provide some descriptions of the parallel feature.

-- 
Thanks
Zhou

> Thanks
> Minfei
>
>> I think the best way is to tell users what it is and how to use it.
>> In kexec, we should tell users how to bring up multiple cpus and
>> what the benefit is.
>> In makedumpfiel, we should tell users how to use multiple threads
>> and what may affect the performance.
>>
>> --
>> Thanks
>> Zhou
>> On 09/08/2015 12:53 PM, Minfei Huang wrote:
>>> On 09/08/15 at 10:51am, "Zhou, Wenjian/周文剑" wrote:
>>>> Hello Minfei,
>>>>
>>>> On 09/08/2015 10:46 AM, Minfei Huang wrote:
>>>>> Hi, Wenjian.
>>>>>
>>>>> How about setting the nr_cpus as default value for parallel dumping?
>>>>> Then we do not need to specify the nr_cpus in kdump.conf.
>>>>>
>>>>
>>>> What do you mean? Do you mean changing the default value of nr_cpus?
>>>
>>> We can use cpu number which is running in the 2nd kernel as the parallel
>>> thread parameter. Thus we do not need to pass the num_thread in
>>> kdump.conf.
>>>
>>>> nr_cpus is set in /etc/sysconfig/kdump not in kdump.conf.
>>>
>>> Due to the Intel CPU bug, we fail to get the exact cpu number used in
>>> the 2nd kernel, if nr_cpus is equal to MAX_CPU(all of the plugged in
>>> machine). if cpu 0 is the crashed cpu, then the booting cpu number is
>>> nr_cpus in 2nd kernel, otherwise is nr_cpus - 1.
>>>
>>> How about adding an option to do this work. Once we pass an option to
>>> open the parallel thread feature in kdump.conf, makedumpfile can get the
>>> max cpu number to create the threads in 2nd kernel.
>>>
>>> Thanks
>>> Minfei
>>>
>>