Deferred inode inactivation and nonblocking inode reclaim

* Deferred inode inactivation and nonblocking inode reclaim
@ 2020-04-22 22:58 Darrick J. Wong
  2020-04-22 23:05 ` [XFS SUMMIT] " Darrick J. Wong
  0 siblings, 1 reply; 3+ messages in thread
From: Darrick J. Wong @ 2020-04-22 22:58 UTC (permalink / raw)
  To: xfs

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
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
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

^ permalink raw reply	[flat|nested] 3+ messages in thread