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@xxxxxxxxxxxxx/ --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
