makedumpfile utility optimization

[Hemanth Siddulugari]

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

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?

-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