Re: [RFC PATCH 0/5] crash dump bitmap: scan memory pages in kernelto speedup kernel dump process

From: Jingbai Ma
Date: Mon Mar 11 2013 - 04:18:10 EST


On 03/08/2013 11:52 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 01:54:45PM -0800, Eric W. Biederman wrote:
Vivek Goyal<vgoyal@xxxxxxxxxx> writes:

On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma wrote:
This patch intend to speedup the memory pages scanning process in
selective dump mode.

Test result (On HP ProLiant DL980 G7 with 1TB RAM, makedumpfile
v1.5.3):

Total scan Time
Original kernel
+ makedumpfile v1.5.3 cyclic mode 1958.05 seconds
Original kernel
+ makedumpfile v1.5.3 non-cyclic mode 1151.50 seconds
Patched kernel
+ patched makedumpfile v1.5.3 17.50 seconds

Traditionally, to reduce the size of dump file, dumper scans all memory
pages to exclude the unnecessary memory pages after capture kernel
booted, and scan it in userspace code (makedumpfile).

I think this is not a good idea. It has several issues.

Actually it does not appear to be doing any work in the first kernel.

Looks like patch3 in series is doing that.

machine_crash_shutdown(&fixed_regs);
+ generate_crash_dump_bitmap();
machine_kexec(kexec_crash_image);

So this bitmap seems to be being set just before transitioning into
second kernel.

I am sure you would not like this extra code in this path. :-)

I was thought this function code is pretty simple, could be called here safely.
If it's not proper for here, how about before the function machine_crash_shutdown(&fixed_regs)?
Furthermore, could you explain the real risks to execute more codes here?

Thanks!


Thanks
Vivek


--
Jingbai Ma (jingbai.ma@xxxxxx)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/