[08/45] mm, x86: Saving vmcore with non-lazy freeing of vmas

[08/45] mm, x86: Saving vmcore with non-lazy freeing of vmas

[Greg KH]

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.

Signed-off-by: Cliff Wickman <cpw@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: kexec@lists.infradead.org
LKML-Reference: <E1OwHZ4-0005WK-Tw@eag09.americas.sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/include/asm/io.h       |    1 +
 arch/x86/kernel/crash_dump_64.c |    1 +
 mm/vmalloc.c                    |    9 +++++++++
 3 files changed, 11 insertions(+)

--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -172,6 +172,7 @@ static inline void __iomem *ioremap(reso
 
 extern void iounmap(volatile void __iomem *addr);
 
+extern void set_iounmap_nonlazy(void);
 
 #ifdef CONFIG_X86_32
 # include "io_32.h"
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -46,6 +46,7 @@ ssize_t copy_oldmem_page(unsigned long p
 	} else
 		memcpy(buf, vaddr + offset, csize);
 
+	set_iounmap_nonlazy();
 	iounmap(vaddr);
 	return csize;
 }
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -513,6 +513,15 @@ static atomic_t vmap_lazy_nr = ATOMIC_IN
 static void purge_fragmented_blocks_allcpus(void);
 
 /*
+ * called before a call to iounmap() if the caller wants vm_area_struct's
+ * immediately freed.
+ */
+void set_iounmap_nonlazy(void)
+{
+	atomic_set(&vmap_lazy_nr, lazy_max_pages()+1);
+}
+
+/*
  * Purges all lazily-freed vmap areas.
  *
  * If sync is 0 then don't purge if there is already a purge in progress.



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

[14/45] x86, kdump: Change copy_oldmem_page() to use cached addressing

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

------------------

From: Cliff Wickman <cpw@sgi.com>

commit 37a2f9f30a360fb03522d15c85c78265ccd80287 upstream.

The copy of /proc/vmcore to a user buffer proceeds much faster
if the kernel addresses memory as cached.

With this patch we have seen an increase in transfer rate from
less than 15MB/s to 80-460MB/s, depending on size of the
transfer. This makes a big difference in time needed to save a
system dump.

Signed-off-by: Cliff Wickman <cpw@sgi.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: kexec@lists.infradead.org
LKML-Reference: <E1OtMLz-0001yp-Ia@eag09.americas.sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/crash_dump_64.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -34,7 +34,7 @@ ssize_t copy_oldmem_page(unsigned long p
 	if (!csize)
 		return 0;
 
-	vaddr = ioremap(pfn << PAGE_SHIFT, PAGE_SIZE);
+	vaddr = ioremap_cache(pfn << PAGE_SHIFT, PAGE_SIZE);
 	if (!vaddr)
 		return -ENOMEM;
 



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

Re: [Stable-review] [08/45] mm, x86: Saving vmcore with non-lazy freeing of vmas

[Ben Hutchings]

[-- 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

Re: [Stable-review] [08/45] mm, x86: Saving vmcore with non-lazy freeing of vmas

[Greg KH]

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@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.

I disagree, it's a major speedup, and an obvious bugfix for the problem.

thanks,

greg k-h

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