[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101122175909.GB18867@suse.de>
Date: Mon, 22 Nov 2010 09:59:09 -0800
From: Greg KH <gregkh@...e.de>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: linux-kernel@...r.kernel.org, stable@...nel.org,
Ingo Molnar <mingo@...e.hu>, kexec@...ts.infradead.org,
Cliff Wickman <cpw@....com>, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org, stable-review@...nel.org,
alan@...rguk.ukuu.org.uk
Subject: Re: [Stable-review] [08/45] mm, x86: Saving vmcore with non-lazy
freeing of vmas
On Sat, Nov 20, 2010 at 02:16:12AM +0000, Ben Hutchings wrote:
> 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@....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.
I disagree, it's a major speedup, and an obvious bugfix for the problem.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists