(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 [email protected] http://lists.infradead.org/mailman/listinfo/kexec
