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
