Re: /proc/vmcore kernel patches

[HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>]

(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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec