All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "Hatayama, Daisuke" <d.hatayama@jp.fujitsu.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lisa.mitchell@hp.com" <lisa.mitchell@hp.com>,
	"kumagai-atsushi@mxc.nes.nec.co.jp"
	<kumagai-atsushi@mxc.nes.nec.co.jp>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"cpw@sgi.com" <cpw@sgi.com>
Subject: Re: [PATCH] kdump, oldmem: support mmap on /dev/oldmem
Date: Tue, 5 Feb 2013 10:12:56 -0500	[thread overview]
Message-ID: <20130205151256.GB12853@redhat.com> (raw)
In-Reply-To: <33710E6CAA200E4583255F4FB666C4E20AC36B01@G01JPEXMBYT03>

On Mon, Feb 04, 2013 at 04:59:35AM +0000, Hatayama, Daisuke wrote:
> Support mmap() on /dev/oldmem to improve performance of reading
> /proc/vmcore. Currently, read to /proc/vmcore is done by read_oldmem()
> that uses ioremap and iounmap per a single page; for example, if
> memory is 1GB, ioremap/iounmap is called (1GB / 4KB)-times, that is,
> 262144 times. This causes big performance degradation.
> 
> By this patch, we saw improvement on simple benchmark from
> 
>   200 [MiB/sec] to over 100.00 [GiB/sec].

Impressve improvement. Thanks for the patch.

[..]
> For design decision, I didn't support mmap() on /proc/vmcore because
> it abstracts old memory as ELF format, so there's range consequtive on
> /proc/vmcore but not consequtive on the actual old memory. For
> example, consider ELF headers on the 2nd kernel and the note objects,
> memory chunks corresponding to PT_LOAD entries on the first kernel.
> They are not consequtive on the old memory. So reampping them so
> /proc/vmcore appears consequtive using existing remap_pfn_range() needs
> some complicated work.

Can't we call remap_pfn_range() multiple times. Once for each sequential
range of memory. /proc/vmcore already has list of contiguous memory areas.
So we can parse user passed file offset and size and map into respective
physical chunks and call rempa_pfn_range() on all these chunks.

I think supporting mmap() both on /dev/oldmem as well as /proc/vmcore will
be nice.

Agreed that supporting mmap() on /proc/vmcore is more work as compared to
/dev/oldmem but should be doable.

Thanks
Vivek

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

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: "Hatayama, Daisuke" <d.hatayama@jp.fujitsu.com>
Cc: "ebiederm@xmission.com" <ebiederm@xmission.com>,
	"cpw@sgi.com" <cpw@sgi.com>,
	"kumagai-atsushi@mxc.nes.nec.co.jp" 
	<kumagai-atsushi@mxc.nes.nec.co.jp>,
	"lisa.mitchell@hp.com" <lisa.mitchell@hp.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kdump, oldmem: support mmap on /dev/oldmem
Date: Tue, 5 Feb 2013 10:12:56 -0500	[thread overview]
Message-ID: <20130205151256.GB12853@redhat.com> (raw)
In-Reply-To: <33710E6CAA200E4583255F4FB666C4E20AC36B01@G01JPEXMBYT03>

On Mon, Feb 04, 2013 at 04:59:35AM +0000, Hatayama, Daisuke wrote:
> Support mmap() on /dev/oldmem to improve performance of reading
> /proc/vmcore. Currently, read to /proc/vmcore is done by read_oldmem()
> that uses ioremap and iounmap per a single page; for example, if
> memory is 1GB, ioremap/iounmap is called (1GB / 4KB)-times, that is,
> 262144 times. This causes big performance degradation.
> 
> By this patch, we saw improvement on simple benchmark from
> 
>   200 [MiB/sec] to over 100.00 [GiB/sec].

Impressve improvement. Thanks for the patch.

[..]
> For design decision, I didn't support mmap() on /proc/vmcore because
> it abstracts old memory as ELF format, so there's range consequtive on
> /proc/vmcore but not consequtive on the actual old memory. For
> example, consider ELF headers on the 2nd kernel and the note objects,
> memory chunks corresponding to PT_LOAD entries on the first kernel.
> They are not consequtive on the old memory. So reampping them so
> /proc/vmcore appears consequtive using existing remap_pfn_range() needs
> some complicated work.

Can't we call remap_pfn_range() multiple times. Once for each sequential
range of memory. /proc/vmcore already has list of contiguous memory areas.
So we can parse user passed file offset and size and map into respective
physical chunks and call rempa_pfn_range() on all these chunks.

I think supporting mmap() both on /dev/oldmem as well as /proc/vmcore will
be nice.

Agreed that supporting mmap() on /proc/vmcore is more work as compared to
/dev/oldmem but should be doable.

Thanks
Vivek

  reply	other threads:[~2013-02-05 15:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04  4:59 [PATCH] kdump, oldmem: support mmap on /dev/oldmem Hatayama, Daisuke
2013-02-05 15:12 ` Vivek Goyal [this message]
2013-02-05 15:12   ` Vivek Goyal
2013-02-06  7:24   ` Hatayama, Daisuke
2013-02-06  7:24     ` Hatayama, Daisuke
2013-02-07 15:06     ` Vivek Goyal
2013-02-07 15:06       ` Vivek Goyal
2013-02-08  0:25       ` Hatayama, Daisuke
2013-02-08  0:25         ` Hatayama, Daisuke
2013-02-08  0:33         ` Hatayama, Daisuke
2013-02-08  0:33           ` Hatayama, Daisuke
2013-02-11 20:44           ` Vivek Goyal
2013-02-11 20:44             ` Vivek Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130205151256.GB12853@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=cpw@sgi.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=kumagai-atsushi@mxc.nes.nec.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lisa.mitchell@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.