[Top] [All Lists]

Re: review: don't hold ilock when calling vn_iowait

To: Timothy Shimmin <tes@xxxxxxx>
Subject: Re: review: don't hold ilock when calling vn_iowait
From: David Chinner <dgc@xxxxxxx>
Date: Tue, 24 Apr 2007 13:08:26 +1000
Cc: David Chinner <dgc@xxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <1A5D0CA3BA5C7CF8B7241F39@timothy-shimmins-power-mac-g5.local>
References: <20070422230303.GX32602149@melbourne.sgi.com> <20070423214338.GA17561@infradead.org> <20070423231706.GO32602149@melbourne.sgi.com> <1A5D0CA3BA5C7CF8B7241F39@timothy-shimmins-power-mac-g5.local>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/
On Tue, Apr 24, 2007 at 12:00:38PM +1000, Timothy Shimmin wrote:
> --On 24 April 2007 9:17:06 AM +1000 David Chinner <dgc@xxxxxxx> wrote:
> >On Mon, Apr 23, 2007 at 10:43:38PM +0100, Christoph Hellwig wrote:
> >>On Mon, Apr 23, 2007 at 09:03:03AM +1000, David Chinner wrote:
> >>>
> >>> Regression introduced by recent freezing fixes - we should
> >>> not hold the ilock while waiting for I/O completion.
> >>
> >>Looks good, and actually simplies the twisted maze the xfs_sync_inodes is
> >>a little bit.  And the missing IPOINTER_INSERT in the SYNC_CLOSE case
> >>looks like an actual bugfix.
> >
> >I had to look closely at that IPOINTER_INSERT case with SYNC_CLOSE;
> >it was actaully working properly because you'd always end up in
> >the SYNC_CLOSE case having inserted a pointer earlier on in the flow
> >of the function. It certainly wasn't obvious that it was doing the
> >right thing, though.
> >
> I find this existing code and the use of marker pointer macros a bit hard 
> to follow.

Doesn't everyone?

> Can you explain where "earlier on in the flow of the function" we've 
> inserted
> the marker pointer (and unlocked the inode-list lock).

I confused that with the removal of the vp == NULL checks I removed.
Too many things, so little time.

So yes, this probably does fix a bug.

> It would be nice if this could be clearer somehow.

Yes, we should be looking to rip all this cruft out because most of
it is redundant - the generic inode writeback does most of this
for us anyway.


Dave Chinner
Principal Engineer
SGI Australian Software Group

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