[PATCH] mm/vmalloc: fix spinning drain_vmap_work after reading from /proc/vmcore

[Baoquan He]

On 04/06/22 at 11:13am, Uladzislau Rezki wrote:
> > On Tue, Apr 05, 2022 at 12:40:31PM -0700, Omar Sandoval wrote:
> > > A simple way to "fix" this would be to make set_iounmap_nonlazy() set
> > > vmap_lazy_nr to lazy_max_pages() instead of lazy_max_pages() + 1. But, I
> > > think it'd be better to get rid of this hack of clobbering vmap_lazy_nr.
> > > Instead, this fix makes __copy_oldmem_page() explicitly drain the vmap
> > > areas itself.
> > 
> > This fixes the bug and the interface also is better than what we had
> > before.  But a vmap/iounmap_eager would seem even better.  But hey,
> > right now it has one caller in always built іn x86 arch code, so maybe
> > it isn't worth spending more effort on this.
> >
> IMHO, it just makes sense to remove it. The set_iounmap_nonlazy() was
> added in 2010 year:
> 
> <snip>
> commit 3ee48b6af49cf534ca2f481ecc484b156a41451d
> Author: Cliff Wickman <cpw at sgi.com>
> Date:   Thu Sep 16 11:44:02 2010 -0500
> 
>     mm, x86: Saving vmcore with non-lazy freeing of vmas
> 
>     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 at sgi.com>
>     Cc: Andrew Morton <akpm at linux-foundation.org>
>     Cc: kexec at lists.infradead.org
>     Cc: <stable at kernel.org>
>     LKML-Reference: <E1OwHZ4-0005WK-Tw at eag09.americas.sgi.com>
>     Signed-off-by: Ingo Molnar <mingo at elte.hu>
> <snip>
> 
> and the reason was the "slow vmap" code, i.e. due to poor performance
> they decided to drop the lazily ASAP. Now we have absolutely different
> picture when it comes to performance and the vmalloc/vmap code.

I would vote for the current code change, removing it. As pointed out by
Christoph, it's only used by x86, may not be so worth to introduce a new
interface.