/proc/vmcore kernel patches

HATAYAMA Daisuke d.hatayama at jp.fujitsu.com
Mon Apr 22 20:38:57 EDT 2013


(2013/04/23 2:55), Cliff Wickman wrote:
> Hello Mr. Atayama and Mr. Kumagai,
>
> I have been playing with the v4 patches
>       kdump, vmcore: support mmap() on /proc/vmcore
> and find the mmap interface to /proc/vmcore potentially about 80x faster than
> the read interface.
>
> But in practice (using a makedumpfile that mmap's instead of read's) I find
> it about 10x slower.
>
> It looks like makedumpfile's usage of the interface is very inefficient.
> It will mmap an area, read a page, then back up the offset to a previous
> page.  It has to munmap and mmap on virtually every read.

You can change size of mapping memory through command-line option 
--map-size <some KB>.

The version of makedumpfile is experimental. The design should be 
changed if it turns out to be problematic.

>
> Do you have a re-worked makedumpfile that predicts a large range of
> pages and mmap's the whole range just once?
> It seems that makedumpfile should have the information available to do
> that.
>

The benchmark result has already shown that under large enough map size, 
the current implementation performs as well as other kernel-space 
implementation that maps a whole range of memory.

In addition, the current implementation of remap_pfn_range uses 4KB 
pages only. This means that total size of PTEs amounts to 2GB per 1TB. 
It's better to map pages little by little for small memory programming.

-- 
Thanks.
HATAYAMA, Daisuke




More information about the kexec mailing list