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" <[email protected]> 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 [email protected] http://lists.infradead.org/mailman/listinfo/kexec
