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

Minfei Huang mhuang at redhat.com
Tue Sep 8 06:37:19 UTC 2015


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).

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


More information about the kexec mailing list