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
