Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753025Ab0K3Mm4 (ORCPT ); Tue, 30 Nov 2010 07:42:56 -0500 Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:17824 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752442Ab0K3Mmz (ORCPT ); Tue, 30 Nov 2010 07:42:55 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKp/9Ex5LdV4/2dsb2JhbACjDHLDAoVHBA Date: Tue, 30 Nov 2010 23:42:49 +1100 From: Nick Piggin To: Jeremy Fitzhardinge Cc: Nick Piggin , "Xen-devel@lists.xensource.com" , Linux Kernel Mailing List , Andrew Morton , Linux Memory Management List , Trond Myklebust , Bryan Schumaker , Konrad Rzeszutek Wilk Subject: Re: [PATCH RFC] vmalloc: eagerly clear ptes on vunmap Message-ID: <20101130124249.GB15778@amd> References: <4CEF6B8B.8080206@goop.org> <20101127103656.GA6884@amd> <4CF40DCB.5010007@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CF40DCB.5010007@goop.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2655 Lines: 73 On Mon, Nov 29, 2010 at 12:32:11PM -0800, Jeremy Fitzhardinge wrote: > When unmapping a region in the vmalloc space, clear the ptes immediately. > There's no point in deferring this because there's no amortization > benefit. > > The TLBs are left dirty, and they are flushed lazily to amortize the > cost of the IPIs. > > This specific motivation for this patch is a regression since 2.6.36 when > using NFS under Xen, triggered by the NFS client's use of vm_map_ram() > introduced in 56e4ebf877b6043c289bda32a5a7385b80c17dee. XFS also uses > vm_map_ram() and could cause similar problems. I do wonder whether there are cache benefits from batching page table updates, especially the batched per cpu maps (and in your version they get double-cleared as well). I think this patch is good, but I think perhaps making it configurable would be nice. So... main question, does it allow Xen to use lazy flushing and avoid vm_unmap_aliases() calls? > > Signed-off-by: Jeremy Fitzhardinge > Cc: Nick Piggin > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index a3d66b3..9960644 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -566,7 +566,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end, > if (va->va_end > *end) > *end = va->va_end; > nr += (va->va_end - va->va_start) >> PAGE_SHIFT; > - unmap_vmap_area(va); > list_add_tail(&va->purge_list, &valist); > va->flags |= VM_LAZY_FREEING; > va->flags &= ~VM_LAZY_FREE; > @@ -616,6 +615,8 @@ static void purge_vmap_area_lazy(void) > */ > static void free_unmap_vmap_area_noflush(struct vmap_area *va) > { > + unmap_vmap_area(va); > + > va->flags |= VM_LAZY_FREE; > atomic_add((va->va_end - va->va_start) >> PAGE_SHIFT, &vmap_lazy_nr); > if (unlikely(atomic_read(&vmap_lazy_nr) > lazy_max_pages())) > @@ -944,8 +945,10 @@ static void vb_free(const void *addr, unsigned long size) > BUG_ON(vb->free); > spin_unlock(&vb->lock); > free_vmap_block(vb); > - } else > + } else { > spin_unlock(&vb->lock); > + vunmap_page_range((unsigned long)addr, (unsigned long)addr + size); > + } > } > > /** > @@ -988,7 +991,6 @@ void vm_unmap_aliases(void) > > s = vb->va->va_start + (i << PAGE_SHIFT); > e = vb->va->va_start + (j << PAGE_SHIFT); > - vunmap_page_range(s, e); > flush = 1; > > if (s < start) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/