[RFC] makedumpfile: Improve reading speed with mmap()

HATAYAMA Daisuke d.hatayama at jp.fujitsu.com
Thu Mar 7 20:45:18 EST 2013


From: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
Subject: Re: [RFC] makedumpfile: Improve reading speed with mmap()
Date: Wed, 6 Mar 2013 18:13:50 +0900

> From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
> Subject: [RFC] makedumpfile: Improve reading speed with mmap()
> Date: Wed, 6 Mar 2013 15:48:04 +0900
> 
>> Hello,
>> 
>> I made the prototype patch to use mmap() on /proc/vmcore for
>> benchmarking.
>> 
>> This patch simply replaces read(2) with mmap(2), I think we can see
>> the pure performance improvement by reducing the number of map/unmap.
>> 
>>   - When /proc/vmcore supports mmap(), readmem() calls read_with_mmap() 
>>     to read /proc/vmcore with mmap() instead of read().
>> 
>>   - Introduce --map-size <Kbyte> option to specify the map size.
>>     This option is necessary to use mmap() in this patch, but just for
>>     benchmarking. I'll remove this option in release version and change
>>     the map size into suitable constant size to get enough performance
>>     improvement.
>> 
>>   - This patch is based on devel branch:
>>     http://makedumpfile.git.sourceforge.net/git/gitweb.cgi?p=makedumpfile/makedumpfile;a=shortlog;h=refs/heads/devel
>> 
>> Unfortunately, I haven't done test and benchmarking in 2nd kernel yet
>> because I can't start up newer kernel as 2nd kernel on my machine.
>> (It seems just my environment issue.) 
>> 
>> At least, this patch works for vmcores saved on local disk,
>> so it will work in 2nd kernel too.
>> 
>> If anyone helps to do benchmarking, it's very helpful for me.
>> And any comments for this patch are welcome.
> 
> Kumagai-san,
> 
> I think it necessary to compare this generic one with the idea
> considering virtual memory mapping, which should affect filtering
> performance to some degree.
> 
> http://lists.infradead.org/pipermail/kexec/2013-February/007982.html
> 
> I guess implementation can relatively be moduler. I'll post a
> prorotype patch for benchmark later.

Sorry, I investigated this around again and now I think this generic
one is enough if size of mmap() range is large enough more than 2MB
that is page size used for mapping virtual memory mapping.

So, let's benchmark this version.

BTW, I think it useful to prepare a temporary branch for this
benchmark for people who help benchmark. It's awkward to manage
patches manually.

Also, I posted the following patch yesterday. The v2 patch for mmap()
on /proc/vmcore needs this since new note type is added in
"VMCOREINFO" name.

[PATCH 0/3] makedumpfile, elf: distinguish ELF note types by ELF note names
http://lists.infradead.org/pipermail/kexec/2013-March/008136.html

Thanks.
HATAYAMA, Daisuke




More information about the kexec mailing list