xfs
[Top] [All Lists]

Re: [PATCH] xfs: force buffer writeback before blocking on the ilock in

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: force buffer writeback before blocking on the ilock in inode reclaim
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sun, 20 Nov 2011 06:46:09 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20111120083345.GO7046@dastard>
References: <20111120072334.GA27386@xxxxxxxxxxxxx> <20111120083345.GO7046@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sun, Nov 20, 2011 at 07:33:45PM +1100, Dave Chinner wrote:
> On Sun, Nov 20, 2011 at 02:23:34AM -0500, Christoph Hellwig wrote:
> > If we are doing synchronous inode reclaim we block the VM from making
> > progress in memory reclaim.  So if we encouter a flush locked inode
> > make sure we force out all delayed buffers ASAP to speed up the wait
> > for it to be unlocked.  Without this we can get hangs of up to 30
> > seconds during workloads hitting synchronous inode reclaim.
> 
> I don't think we need to push out all delayed buffers - that's an
> awfully big sledge hammer to get a single buffer moving. Indeed, we
> already have a mechanism for dealing with this problem -
> xfs_buf_delwri_promote() - when we hit it during AIL flushing.
> 
> IOWs, we only need to promote the buffer the inode sits in and kick
> xfsbufd. that is, something like:
> 
>         bp = xfs_incore(ip->i_mount->m_ddev_targp, iip->ili_format.ilf_blkno,
>                         iip->ili_format.ilf_len, XBF_TRYLOCK);
>         if (bp && XFS_BUF_ISDELAYWRITE(bp)) {
>                 xfs_buf_delwri_promote(bp);
>               wake_up_process(mp->m_ddev_targp->bt_task);
>       }
>       if (bp)
>               xfs_buf_relse(bp);

Yes, we could try a variant of that.  Note that a buffer in synchronous
reclaim isn't guaranteed to actually have a log item, but we can get
the same information from ip->i_imap.

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