[PATCH v2] Improve the performance of --num-threads -d 31

"Zhou, Wenjian/周文剑" zhouwj-fnst at cn.fujitsu.com
Mon Feb 22 21:47:18 PST 2016


Hello, Minfei,

Does it occur every time?
If not, I think I have known the reason.

-- 
Thanks
Zhou

On 02/23/2016 01:26 PM, Minfei Huang wrote:
> On 02/23/16 at 12:58am, Minfei Huang wrote:
>> On 02/17/16 at 03:05pm, Zhou Wenjian wrote:
>>> The new implementation won't do the extra work for filtered pages any
>>> more. So the performance of -d 31 is close to that of serial processing.
>>
>> Hi, Wenjian.
>>
>> kdump:/# time bash -x a.sh makedumpfile vmcore02 1 --num-threads 128
>> + makedumpfile --num-threads -l --message-level 1 -d 31 /proc/vmcore /kdumproot/home//var/crash/127.0.0.1-2016-02-22-23:22:36/vmcore02
>
> Please ignore this benchmark, since there is no parameter passed to
> option num-threads. Following is my new test result which is generated
> in 1st kernel.
>
> 127.0.0.1-2016-02-22-19\:08\:17/vmcore01 is generated by makedumpfile
> with -d 31 in 2nd kernel.
>>
>> Command makedumpfile is complied with this patch on version 1.5.9, and
>> makedumpfile.backup is complied on version 1.5.7.
>>
>> The compressed file vmcore is 67G filtered out from 4T memory.
>
> [crash]# time makedumpfile -l --message-level 1 -d 31 127.0.0.1-2016-02-22-19\:08\:17/vmcore01 vmcore10
> Copying data                       : [100.0 %] /
>
> real    7m25.492s
> user    6m37.386s
> sys 0m47.801s
> [crash]# time makedumpfile.backup -l --message-level 1 -d 31 127.0.0.1-2016-02-22-19\:08\:17/vmcore01 vmcore11
> Copying data                       : [100.0 %] -
>
> real    7m15.784s
> user    6m28.829s
> sys 0m46.656s
>
> [crash]# time makedumpfile --num-threads 128 -l --message-level 1 -d 31 127.0.0.1-2016-02-22-19\:08\:17/vmcore01
> vmcore14
> Copying data                       : [ 99.7 %] |
>
> Never return from makedumpfile.
>
> There are more than 128 cpus plugged in this machine.
>
> Thanks
> Minfei
>
>








More information about the kexec mailing list