On 09/08/15 at 01:57pm, "Zhou, Wenjian/周文剑" wrote:
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
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
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).
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.
On 09/08/2015 12:53 PM, Minfei Huang wrote:
>On 09/08/15 at 10:51am, "Zhou, Wenjian/周文剑" wrote:
>>On 09/08/2015 10:46 AM, Minfei Huang wrote:
>>>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
>>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.