[Top] [All Lists]

Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly.

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly.
From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Date: Tue, 17 Mar 2009 09:15:13 -0400 (EDT)
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20090316091331.GC2636@xxxxxxxxxxxxx>
References: <1237116707-25793-1-git-send-email-david@xxxxxxxxxxxxx> <1237116707-25793-4-git-send-email-david@xxxxxxxxxxxxx> <20090316091331.GC2636@xxxxxxxxxxxxx>
On Mon, 16 Mar 2009, Christoph Hellwig wrote:

> On Sun, Mar 15, 2009 at 10:31:45PM +1100, Dave Chinner wrote:
> > xfs_flush_inodes() currently uses a magic timeout to wait for
> > some inodes to be flushed before returning. This isn't
> > really reliable but used to be the best that could be done
> > due to deadlock potential of waiting for the entire flush.
> > 
> > Now the inode flush is safe to execute while we hold page
> > and inode locks, we can wait for all the inodes to flush
> > synchronously. Convert the wait mechanism to a completion
> > to do this efficiently. This should remove all remaining
> > spurious ENOSPC errors from the delayed allocation reservation
> > path.
> Why do we queue it up to a different thread if we synchronously wait
> for it anyway?

The good thing is that it saves a bit of stack space. ... And the bad 
thing of that it avoids lockdep warnings, because the lockdep engine 
cannot track dependence of processes via completions. (I tried to call it 
directly and there are none warnings, though for long-term development it 
would be better to allow the warnings so that deadlocks could be fixed 
before they hurt someone).


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