WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [patch] Re: Interaction between Xen and XFS: stray RW ma

To: Andi Kleen <andi@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [patch] Re: Interaction between Xen and XFS: stray RW mappings
From: David Chinner <dgc@xxxxxxx>
Date: Tue, 23 Oct 2007 22:41:37 +1000
Cc: Nick Piggin <nickpiggin@xxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, David Chinner <dgc@xxxxxxx>, dean gaudet <dean@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Bøgeskov <xen-users@xxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, xfs-masters@xxxxxxxxxxx, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Morten@xxxxxxx, Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Delivery-date: Tue, 23 Oct 2007 05:42:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071023093035.GB24536@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.0.9999.0710212015430.2320@xxxxxxxxxxxxxxxxxxx> <471C1A61.1010001@xxxxxxxx> <p73sl439s7k.fsf@xxxxxxxxxxxxxx> <471CEEB4.9040807@xxxxxxxx> <20071022190740.GA1695@xxxxxxxxxxxxxxxxxx> <20071022223224.GC995458@xxxxxxx> <20071022233514.GA9057@xxxxxxxxxxxxxxxxxx> <20071023003641.GF995458@xxxxxxx> <20071023070414.GM66820511@xxxxxxx> <20071023093035.GB24536@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Tue, Oct 23, 2007 at 11:30:35AM +0200, Andi Kleen wrote:
> On Tue, Oct 23, 2007 at 05:04:14PM +1000, David Chinner wrote:
> > > You mean like vmap() could record the pages passed to it in the 
> > > area->pages
> > > array, and we walk and release than in __vunmap() like it already does
> > > for vfree()?
> > > 
> > > If we did this, it would probably be best to pass a page release function
> > > into the vmap or vunmap call - we'd need page_cache_release() called on
> > > the page rather than __free_page()....
> > > 
> > > The solution belongs behind the vmap/vunmap interface, not in XFS....
> > 
> > Lightly tested(*) patch that does this with lazy unmapping
> > below for comment.
> 
> Thanks
> 
> > 
> > (*) a) kernel boots, b) made an XFS filesystem with 64k directory
> > blocks, created ~100,000 files in a directory to get a wide btree
> > (~1700 blocks, still only a single level) and run repeated finds
> > across it dropping caches in between.  Each traversal maps and
> > unmaps every btree block.
> 
> Hmm, the __free_page -> page_cache_release() change in vfree() would
> have been simpler wouldn't it? 

Yes, it would, but I tried to leave vmalloc doing the same thing as
it was before. I think that it would be safe simply to call put_page()
directly in the __vunmap() code and drop all the release function
passing, but I don't know enough about that code to say for certain.
I'll spin up another patch tomorrow that does this and see how it goes.

> But if it works it is fine.

Seems to - it's passed XFSQA with 64k directories and a bunch of
dirstress workouts as well.

Nick, Jeremy, (others?) any objections to this approach to solve
the problem?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>