From: Ben Hutchings <ben@decadent.org.uk>
To: Greg KH <gregkh@suse.de>
Cc: akpm@linux-foundation.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@kernel.org,
stable-review@kernel.org, Ingo Molnar <mingo@elte.hu>,
torvalds@linux-foundation.org, Cliff Wickman <cpw@sgi.com>,
alan@lxorguk.ukuu.org.uk
Subject: Re: [Stable-review] [08/45] mm, x86: Saving vmcore with non-lazy freeing of vmas
Date: Sat, 20 Nov 2010 02:16:12 +0000 [thread overview]
Message-ID: <1290219372.3818.113.camel@localhost> (raw)
In-Reply-To: <20101119214410.087440440@clark.site>
[-- Attachment #1.1: Type: text/plain, Size: 979 bytes --]
On Fri, 2010-11-19 at 13:42 -0800, Greg KH wrote:
> 2.6.32-stable review patch. If anyone has any objections, please let us know.
>
> ------------------
>
> From: Cliff Wickman <cpw@sgi.com>
>
> commit 3ee48b6af49cf534ca2f481ecc484b156a41451d upstream.
>
> During the reading of /proc/vmcore the kernel is doing
> ioremap()/iounmap() repeatedly. And the buildup of un-flushed
> vm_area_struct's is causing a great deal of overhead. (rb_next()
> is chewing up most of that time).
>
> This solution is to provide function set_iounmap_nonlazy(). It
> causes a subsequent call to iounmap() to immediately purge the
> vma area (with try_purge_vmap_area_lazy()).
>
> With this patch we have seen the time for writing a 250MB
> compressed dump drop from 71 seconds to 44 seconds.
[...]
Useful, but it doesn't seem to meet the criteria for stable updates.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2010-11-20 2:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101119214439.GA26350@kroah.com>
2010-11-19 21:42 ` [08/45] mm, x86: Saving vmcore with non-lazy freeing of vmas Greg KH
2010-11-20 2:16 ` Ben Hutchings [this message]
2010-11-22 17:59 ` [Stable-review] " Greg KH
2010-11-19 21:42 ` [14/45] x86, kdump: Change copy_oldmem_page() to use cached addressing Greg KH
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=1290219372.3818.113.camel@localhost \
--to=ben@decadent.org.uk \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cpw@sgi.com \
--cc=gregkh@suse.de \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=stable-review@kernel.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
/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