public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: kexec@lists.infradead.org, heiko.carstens@de.ibm.com,
	linux-kernel@vger.kernel.org, lisa.mitchell@hp.com,
	kumagai-atsushi@mxc.nes.nec.co.jp, zhangyanfei@cn.fujitsu.com,
	akpm@linux-foundation.org, cpw@sgi.com, vgoyal@redhat.com
Subject: Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore
Date: Wed, 20 Mar 2013 23:16:20 -0700	[thread overview]
Message-ID: <87d2ut2s7f.fsf@xmission.com> (raw)
In-Reply-To: <20130321.125245.142520187.d.hatayama@jp.fujitsu.com> (HATAYAMA Daisuke's message of "Thu, 21 Mar 2013 12:52:45 +0900 (JST)")

HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> writes:

> From: Andrew Morton <akpm@linux-foundation.org>
> Subject: Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore
> Date: Tue, 19 Mar 2013 12:30:05 -0700
>
>> On Sat, 16 Mar 2013 13:00:47 +0900 HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
>> 
>>> Currently, read to /proc/vmcore is done by read_oldmem() that uses
>>> ioremap/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.
>>> 
>>> In particular, the current main user of this mmap() is makedumpfile,
>>> which not only reads memory from /proc/vmcore but also does other
>>> processing like filtering, compression and IO work. Update of page
>>> table and the following TLB flush makes such processing much slow;
>>> though I have yet to make patch for makedumpfile and yet to confirm
>>> how it's improved.
>>> 
>>> To address the issue, this patch implements mmap() on /proc/vmcore to
>>> improve read performance. My simple benchmark shows the improvement
>>> from 200 [MiB/sec] to over 50.0 [GiB/sec].
>> 
>> There are quite a lot of userspace-visible vmcore changes here.  Is it
>> all fully back-compatible?  Will all known userspace continue to work
>> OK on newer kernels?
>> 
>
> I designed it to keep backward-compatibility at least for gdb and
> binutils but not less for makedumpfile since it should follow kernel
> changes; old makedumpfile cannot use newer kernels, and this is within
> the range of this review.

To the extent possible we should different versions of tools to be
interchanged.  That helps with bug hunting and for people who are in
resource constrained systems that build old versions of the tools that
are tiny and fit.

Given that rounding the per cpu NOTES turns out to be a waste of memory
I didn't see anything in the patchset that justfies any breakage.

Eric


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

  reply	other threads:[~2013-03-21  6:16 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-16  4:00 [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore HATAYAMA Daisuke
2013-03-16  4:00 ` [PATCH v3 01/21] vmcore: reference e_phoff member explicitly to get position of program header table HATAYAMA Daisuke
2013-03-19 21:44   ` Eric W. Biederman
2013-03-21  2:50     ` HATAYAMA Daisuke
2013-03-21  6:11       ` Eric W. Biederman
2013-03-21 14:12       ` Vivek Goyal
2013-03-22  0:25         ` HATAYAMA Daisuke
2013-03-16  4:00 ` [PATCH v3 02/21] vmcore: clean up by removing unnecessary variable HATAYAMA Daisuke
2013-03-16  4:01 ` [PATCH v3 03/21] vmcore: rearrange program headers without assuming consequtive PT_NOTE entries HATAYAMA Daisuke
2013-03-19 21:59   ` Eric W. Biederman
2013-03-16  4:01 ` [PATCH v3 04/21] vmcore, sysfs: export ELF note segment size instead of vmcoreinfo data size HATAYAMA Daisuke
2013-03-16  4:01 ` [PATCH v3 05/21] vmcore: allocate buffer for ELF headers on page-size alignment HATAYAMA Daisuke
2013-03-16  4:01 ` [PATCH v3 06/21] vmcore: round up buffer size of ELF headers by PAGE_SIZE HATAYAMA Daisuke
2013-03-19 22:07   ` Eric W. Biederman
2013-03-16  4:01 ` [PATCH v3 07/21] vmcore, procfs: introduce a flag to distinguish objects copied in 2nd kernel HATAYAMA Daisuke
2013-03-19 19:35   ` Andrew Morton
2013-03-16  4:01 ` [PATCH v3 08/21] vmcore: copy non page-size aligned head and tail pages " HATAYAMA Daisuke
2013-03-19 19:37   ` Andrew Morton
2013-03-19 20:59   ` Eric W. Biederman
2013-03-19 21:22     ` Vivek Goyal
2013-03-19 23:35       ` Eric W. Biederman
2013-03-16  4:01 ` [PATCH v3 09/21] vmcore: modify vmcore clean-up function to free buffer on " HATAYAMA Daisuke
2013-03-16  4:01 ` [PATCH v3 10/21] vmcore: clean up read_vmcore() HATAYAMA Daisuke
2013-03-16  4:01 ` [PATCH v3 11/21] vmcore: read buffers for vmcore objects copied from old memory HATAYAMA Daisuke
2013-03-16  4:01 ` [PATCH v3 12/21] vmcore: allocate per-cpu crash_notes objects on page-size boundary HATAYAMA Daisuke
2013-03-19 21:06   ` Eric W. Biederman
2013-03-19 22:12   ` Eric W. Biederman
2013-03-20 13:48     ` Vivek Goyal
2013-03-20 20:48       ` Eric W. Biederman
2013-03-16  4:02 ` [PATCH v3 13/21] kexec: allocate vmcoreinfo note buffer " HATAYAMA Daisuke
2013-03-19 21:07   ` Eric W. Biederman
2013-03-19 22:12   ` Eric W. Biederman
2013-03-16  4:02 ` [PATCH v3 14/21] kexec, elf: introduce NT_VMCORE_DEBUGINFO note type HATAYAMA Daisuke
2013-03-16  4:02 ` [PATCH v3 15/21] elf: introduce NT_VMCORE_PAD type HATAYAMA Daisuke
2013-03-16  4:02 ` [PATCH v3 16/21] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary HATAYAMA Daisuke
2013-03-19 22:17   ` Eric W. Biederman
2013-03-16  4:02 ` [PATCH v3 17/21] vmcore: check NT_VMCORE_PAD as a mark indicating the end of ELF note buffer HATAYAMA Daisuke
2013-03-19 21:11   ` Eric W. Biederman
2013-03-21  2:59     ` HATAYAMA Daisuke
2013-03-21  3:54       ` Eric W. Biederman
2013-03-21 14:36         ` Vivek Goyal
2013-03-22  0:30           ` HATAYAMA Daisuke
2013-03-22  0:41             ` Eric W. Biederman
2013-03-19 22:20   ` Eric W. Biederman
2013-03-16  4:02 ` [PATCH v3 18/21] vmcore: check if vmcore objects satify mmap()'s page-size boundary requirement HATAYAMA Daisuke
2013-03-19 20:02   ` Andrew Morton
2013-03-19 21:22     ` Eric W. Biederman
2013-03-20 13:51     ` Vivek Goyal
2013-03-19 22:38   ` Eric W. Biederman
2013-03-20 13:57     ` Vivek Goyal
2013-03-20 20:55       ` Eric W. Biederman
2013-03-21  3:25         ` HATAYAMA Daisuke
2013-03-21  4:18           ` Eric W. Biederman
2013-03-21  6:14             ` HATAYAMA Daisuke
2013-03-21  6:29               ` Eric W. Biederman
2013-03-21  6:46                 ` HATAYAMA Daisuke
2013-03-21  7:07                   ` Eric W. Biederman
2013-03-21 15:21                     ` Vivek Goyal
2013-03-21 15:27                       ` Vivek Goyal
2013-03-22  0:43                         ` HATAYAMA Daisuke
2013-03-22  0:54                         ` Eric W. Biederman
2013-03-22  2:30                           ` HATAYAMA Daisuke
2013-03-21 14:57                 ` Vivek Goyal
2013-03-21  7:22               ` Eric W. Biederman
2013-03-21 14:49                 ` Vivek Goyal
2013-03-22  7:11                   ` HATAYAMA Daisuke
2013-03-21 13:50         ` Vivek Goyal
2013-03-16  4:02 ` [PATCH v3 19/21] vmcore: round-up offset of vmcore object in page-size boundary HATAYAMA Daisuke
2013-03-16  4:02 ` [PATCH v3 20/21] vmcore: count holes generated by round-up operation for vmcore size HATAYAMA Daisuke
2013-03-16  4:02 ` [PATCH v3 21/21] vmcore: introduce mmap_vmcore() HATAYAMA Daisuke
2013-03-19 19:30 ` [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore Andrew Morton
2013-03-21  3:52   ` HATAYAMA Daisuke
2013-03-21  6:16     ` Eric W. Biederman [this message]
2013-03-21  6:35       ` HATAYAMA Daisuke
2013-03-21  7:14         ` Eric W. Biederman
2013-03-19 23:16 ` Eric W. Biederman

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=87d2ut2s7f.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=cpw@sgi.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=heiko.carstens@de.ibm.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 \
    --cc=vgoyal@redhat.com \
    --cc=zhangyanfei@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox