[XFS SUMMIT] Deferred inode inactivation and nonblocking inode reclaim

["Darrick J. Wong" <darrick.wong@oracle.com>]

Heh, only after I sent this did I think about tagging the subject line
and sending links to git branches when applicable.

On Wed, Apr 22, 2020 at 03:58:51PM -0700, Darrick J. Wong wrote:
> Hi everyone,
> 
> Here's a jumping-off point for a discussion about my patchset that
> implements deferred inode inactivation and Dave's patchset that moves
> inode buffer flushing out of reclaim.
> 
> The inactivation series moves the transactional updates that happen

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=deferred-inactivation

> after a file loses its last reference (truncating attr/data forks,
> freeing the inode) out of drop_inode and reclaim by moving all that work
> to an intermediate workqueue.  This all can be done internally to XFS.
> 
> The reclaim series (Dave) removes inode flushing from reclaim, which

https://lore.kernel.org/linux-xfs/20191031234618.15403-1-david@fromorbit.com/

--D

> means that xfs stop holding up memory reclaim on IO.  It also contains a
> fair amount of surgery to the memory shrinker code, which is an added
> impediment to getting this series reviewed and upstream.
> 
> Because of the extra review needed for the reclaim series, does it make
> sense to keep the two separate?  Deferring inactivation alone won't get
> rid of the inode flushing that goes on in reclaim, but it at least means
> that we can handle things like "rm -rf $dir" a little more efficiently
> in that we can do all the directory shrinking at once and then handle
> the unlinked inodes in on-disk order.  It would also, erm, help me
> reduce the size of my dev tree. :)
> 
> --D