xfs
[Top] [All Lists]

Re: [PATCH 3/5] xfs: convert ENOSPC inode flushing to use new syncd work

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 3/5] xfs: convert ENOSPC inode flushing to use new syncd workqueue
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 4 Mar 2011 07:40:18 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, chris.mason@xxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <20110303224105.GP15097@dastard>
References: <1298412969-14389-1-git-send-email-david@xxxxxxxxxxxxx> <1298412969-14389-4-git-send-email-david@xxxxxxxxxxxxx> <20110303153410.GA27205@xxxxxxxxxxxxx> <20110303224105.GP15097@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Mar 04, 2011 at 09:41:05AM +1100, Dave Chinner wrote:
> On Thu, Mar 03, 2011 at 10:34:10AM -0500, Christoph Hellwig wrote:
> > I still don't see any point in having the ENOSPC flushing moved to a
> > different context.
> 
> IIRC, stack usage has always been an issue, and we also call
> xfs_flush_inodes() with the XFS_IOLOCK held (from
> xfs_iomap_write_delay()) so the alternate context was used to avoid
> deadlocks. I don't think we have that deadlock problem now thanks to
> being able to combine SYNC_TRYLOCK | SYNC_WAIT flags, but I'm not
> sure we can ignore the stack issues.

Given that we wait for completion of the syncing in the caller moving it
to a different context does not help with any deadlocks.  It just makes
them impossible to detect using lockdep.

> I've also realised the work_pending() check is unnecessary, as is
> the lock, because queue_work() will only queue new work if the work
> item isn't already pending so there's no need to check it here.
> Hence all this actually needs to do is:
> 
>       queue_work()
>       flush_work_sync()

or in fact only use the writeback_inodes_sb_if_idle call you added
later.  That also causes writeback of data from the flusher threads.

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