[PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore

[Eric W. Biederman]

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

> From: Andrew Morton <akpm at 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 at 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