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.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
