/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