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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Atsushi Kumagai <kumagai-atsushi@xxxxxxxxxxxxxxxxx>
Subject: Re: [RFC] makedumpfile: Improve reading speed with mmap()
Date: Fri, 8 Mar 2013 11:33:32 +0900

> Hello HATAYAMA-san,
> 
> On Fri, 08 Mar 2013 10:45:18 +0900 (JST)
> HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:
> 
>> 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.
> 
> Yes, I thought that I should prepare such a branch when the patch for
> benchmark is fixed, and now is the time.
> 
>> 
>> 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
> 
> Now, I can't get the chance to review the patch set above.
> But, anyway, I created the branch "mmap":
> 
> http://makedumpfile.git.sourceforge.net/git/gitweb.cgi?p=makedumpfile/makedumpfile;a=shortlog;h=refs/heads/mmap
> 
> Please use it for benchmark.

Thanks! It's very helpful.

Also, I tested a little the mmap branch code and found a small bug
that max file offset used in calculating mmap()'s position is
wrong. Please see the next patch.

# But sorry, I made this quickly so I didn't consider design enough.

>From 77ef0e836bba4713bfb578949d2785962179d630 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke <d.hatayama@xxxxxxxxxxxxxx>
Date: Sat, 9 Mar 2013 13:49:43 +0900
Subject: [PATCH] makedumpfile: fix max offset relative to file

To see file offset of each memory chunk, it's correct to read p_offset
in the corresponing PT_LOAD entrie.

On /proc/vmcore PT_LOAD entries are sorted on p_load values in
increasing order. So, it's sufficient to refer to the last PT_LOAD
entry only. But the code here doesn't assuming that, calculating
maximum one from all the PT_LOAD entries.

Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
---
 elf_info.c     | 12 ++++++++++++
 elf_info.h     |  2 ++
 makedumpfile.c |  2 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/elf_info.c b/elf_info.c
index 9bd8cd0..aa8cacb 100644
--- a/elf_info.c
+++ b/elf_info.c
@@ -45,6 +45,7 @@ struct pt_load_segment {
 };
 
 static int			nr_cpus;             /* number of cpu */
+static off_t			max_file_offset;
 
 /*
  * File information about /proc/vmcore:
@@ -637,6 +638,12 @@ get_elf_info(int fd, char *filename)
 			return FALSE;
 		j++;
 	}
+	max_file_offset = 0;
+	for (i = 0; i < num_pt_loads; ++i) {
+		struct pt_load_segment *p = &pt_loads[i];
+		max_file_offset=MAX(max_file_offset,
+				    p->file_offset+p->phys_end-p->phys_start);
+	}
 	if (!has_pt_note()) {
 		ERRMSG("Can't find PT_NOTE Phdr.\n");
 		return FALSE;
@@ -869,3 +876,8 @@ set_eraseinfo(off_t offset, unsigned long size)
 	size_eraseinfo   = size;
 }
 
+off_t
+get_max_file_offset(void)
+{
+	return max_file_offset;
+}
diff --git a/elf_info.h b/elf_info.h
index eb58023..61ab3c9 100644
--- a/elf_info.h
+++ b/elf_info.h
@@ -71,6 +71,8 @@ int has_eraseinfo(void);
 void get_eraseinfo(off_t *offset, unsigned long *size);
 void set_eraseinfo(off_t offset, unsigned long size);
 
+off_t get_max_file_offset(void);
+
 #endif  /* ELF_INFO_H */
 
 
diff --git a/makedumpfile.c b/makedumpfile.c
index 3351158..7acbf72 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -235,7 +235,7 @@ static int
 update_mmap_range(off_t offset) {
 	off_t start_offset;
 	off_t map_size;
-	off_t max_offset = info->max_mapnr * info->page_size;
+	off_t max_offset = get_max_file_offset();
 
 	munmap(info->mmap_buf,
 	       info->mmap_end_offset - info->mmap_start_offset);
-- 
1.8.1.4





[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux