kumagai-atsushi at mxc.nes.nec.co.jp
Thu Oct 25 00:07:36 EDT 2012
On Tue, 23 Oct 2012 17:51:05 -0500
Cliff Wickman <cpw at sgi.com> wrote:
> Hello Mr. Kumagai,
> I was looking for some information about the "cyclic" processing in
> makedumpfile, and came upon this:
> That's why I'm sending this question to you.
Thank you for your suggestion for improvement.
> I work on the Linux kernel here at SGI. We are trying to dump some very
> large memories, and so we are very interested in this cyclic feature.
> I built makedumpfile-1.5.0 and tried it out.
> It seems to work fine, but does spend a lot of time building bitmaps.
> If I set the cyclic-buffer value to create 3 cycles, then
> exclude_unneccessary_pages_cyclic() is entered 6 times:
> - 3 times from get_num_dumpable_cyclic() (via update_region_cyclic())
> - 3 times from write_kdump_pages_and_bitmap_cyclic()
> (also via update_region_cyclic())
> These page structure scans of /proc/vmcore for terabytes of memory can
> take a long time, and so I think something might be done to remove the
> redundant scans.
> Could it not be possible to save the bitmaps created during the
> get_num_dumpable_cyclic() pass? And then retrieve them for the
> write_kdump_pages_and_bitmap_cyclic() pass? I think this could save
> literally hours on a very large memory.
> Perhaps they could be written to a file, or files.
makedumpfile should work also on the environment which doesn't mount a root
filesystem when 2nd-kernel is running. In such environments, writing to a file
isn't the solution because the bitmap file is created on 2nd-kernel's memory.
This is the starting point of our discussion.
Therefore, we can save only a chunk of bitmap at a time, so we have to scan
each region twice.
> But I'm sure you understand the logic of makedumpfile much better than I.
> Do you think such an enhancement is possible?
> Or perhaps you already have another workaround?
Now, I plan to do the two enhancement for performance, please see below.
- Minimaize the number of cycle
- Improve the filtering logic
> Thanks much.
> -Cliff Wickman
More information about the kexec