[Top] [All Lists]

Re: [PATCH 0/9] stop taking the iolock in the reclaim path

To: xfs@xxxxxxxxxxx
Subject: Re: [PATCH 0/9] stop taking the iolock in the reclaim path
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 25 Aug 2009 14:41:30 -0400
In-reply-to: <20090825182134.299870049@xxxxxxxxxxxxxxxxxxxxxx>
References: <20090825182134.299870049@xxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.19 (2009-01-05)
Ah sorry, I resent the old lockdep patches,  Will send the real one

On Tue, Aug 25, 2009 at 02:21:34PM -0400, Christoph Hellwig wrote:
> Currently we take the iolock in the reclaim path in various places.
> Taking it in the inode reclaim path means however that we can't take
> it while doing memory allocations that recurse back into the filesystem,
> and recently lockdep has been enhanced to find these cases and noticed
> quite a few of these in XFS.
> We had similar issues with the ilock, but we could get away with just
> stopping to do filesystem-recursing allocation under the ilock as there
> were just a few.  The iolock is however taken over larger critical sections
> protection actual I/O and it's almost impossible to switch all these to
> NOFS allocations.  Based on what the iolock is used for we don't actually
> need it in the reclaim path, though - at this point the inode is dead
> and no one has any other reference to it.  See the listing in the
> first patch for a more detailed list of our current iolock holders and
> why they can't contend with the reclaim path.
> I would greatly appreciate some indepth-review of this to make sure I
> haven't missed a big loophole..
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
---end quoted text---

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