Re: [PATCH] makedumpfile: Use file offset in initialize_mmap()

From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: kexec mailing list <kexec@lists.infradead.org>,
	Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>,
	Jan Willeke <willeke@de.ibm.com>
Subject: Re: [PATCH] makedumpfile: Use file offset in initialize_mmap()
Date: Tue, 3 Mar 2015 10:15:43 +0100	[thread overview]
Message-ID: <20150303101543.416b5cb4@holzheu> (raw)
In-Reply-To: <20150227131409.33dd14a4@hananiah.suse.cz>

Hello Petr,

Thanks for the fix!

Hard to believe that makedumpfile mmap mode on s390 has never worked.

On Fri, 27 Feb 2015 13:14:09 +0100
Petr Tesarik <ptesarik@suse.cz> wrote:

> Hi all,
> 
> update_mmap_range() expects a file offset as its first argument, but
> initialize_mmap() passes a physical address. Since the first segment
> usually starts at physical addr 0 on S/390, but there is no segment 
> at file offset 0, update_mmap_range() fails, and makedumpfile falls
> back to read().

And for other architectures the wrong parameter was no problem?

> 
> @Michael: I wonder how you actually tested the kernel mmap patches;
> this bug has prevented mmap on all my s390 systems...

We tested /proc/vmcore mmap with our SCSI stand-alone dump (zfcpdump) and
with small test programs that used mmap.

I did a quick test with your patch and it looks like the mmap mode
on my s390 system is slower than the read mode:

# time ./makedumpfile -d 31 /proc/vmcore out
real    0m1.043s
user    0m0.187s
sys     0m0.433s

# time ./makedumpfile -d 31 /proc/vmcore out --non-mmap
real    0m0.767s
user    0m0.098s
sys     0m0.364s

We will have to look into this.

Michael

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec