makedumpfile utility optimization

[Atsushi Kumagai]

>Atsushi,
>
>Thanks a lot for a quick reply.
>
>These results are on the following processor: E5504  @ 2.00GHz
>We are running with SMP disabled (to be on the conservative side) so only
>one CPU.
>The dumpable pages were ~50000 out of 0x3c0000 (16G of RAM).
>After dumping about 50000, it took more than 30 minutes to evaluate the
>rest of the pages so our watchdog fired.
>I put a print statement to print progress after processing every 10,000
>pfns and I noticed that it was taking approximately 5 seconds to process
>10,000 pfns (there must be something else going on that I¹ll need to look
>into).

Thanks for your report, it sounds good improvement.

>Anyway, thanks for the confirmation that it is safe to use my patch.
>Do you want me to commit my patch to the source of makedumpfile?

Yeah, I'll be happy to get your patch.
For that, I would like you to rebase the patch on the devel branch.

  https://sourceforge.net/p/makedumpfile/code/ci/devel/tree/

Recent makedumpfile have multithread feature, it calls write_kdump_pages_parallel_cyclic()
instead of write_kdump_pages_cyclic(), so you need to modify it too.


Thanks,
Atsushi Kumagai

>-Hemanth
>
>
>On 4/14/16, 10:24 PM, "Atsushi Kumagai" <ats-kumagai at wm.jp.nec.com> wrote:
>
>>(CC'ing kexec-ML)
>>
>>Hello Hemanth,
>>
>>>Hi 'makedumpfile' utility developers,
>>>
>>>I'm using version 1.5.6 and I see that we can optimize the utility using
>>>this patch:
>>>
>>>--- makedumpfile-1.5.6/makedumpfile.c   2014-04-20 18:59:18.000000000
>>>-0700
>>>+++ makedumpfile-1.5.6-changed/makedumpfile.c   2016-04-11
>>>18:47:50.019563738 -0700
>>>@@ -6475,6 +6475,15 @@
>>>
>>>        for (pfn = start_pfn; pfn < end_pfn; pfn++) {
>>>
>>>+               /*
>>>+                * There's no point in checking other pages if we've
>>>already dumped
>>>+                * all the pages that are dumpable
>>>+                */
>>>+               if (num_dumped == info->num_dumpable) {
>>>+                       ret = TRUE;
>>>+                       goto out;
>>>+               }
>>>+
>>>                if ((num_dumped % per) == 0)
>>>                        print_progress(PROGRESS_COPY, num_dumped,
>>>info->num_dumpable);
>>>
>>>Why are we looping even after we are done with all the dumpable pages to
>>>start with?
>>>I'm concerned if I'm missing something with this patch.
>>
>>You are right, it's better to break the loop after the last dumpable page
>>is written. I neglected that since the remains of loop just check the
>>bitmap and call continue, I thought the wasteful processing cost is
>>little.
>>I'm curious to know how much does this patch improve the performance.
>>
>>
>>Thanks,
>>Atsushi Kumagai
>
>
>_______________________________________________
>kexec mailing list
>kexec at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec