(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
