Re: [PATCH 06/11] xfs: deferred inode inactivation

Christoph Hellwig
2021-03-17T15:49:23Z

On Tue, Mar 16, 2021 at 08:47:29AM -0700, Darrick J. Wong wrote:
> On Tue, Mar 16, 2021 at 07:27:10AM +0000, Christoph Hellwig wrote:
> > Still digesting this. What trips me off a bit is the huge amount of
> > duplication vs the inode reclaim mechanism. Did you look into sharing
> > more code there and if yes what speaks against that?
>
> TBH I didn't look /too/ hard because once upon a time[1] Dave was aiming
> to replace the inode reclaim tagging and iteration with an lru list walk
> so I decided not to entangle the two.
>
> [1] https://lore.kernel.org/linux-xfs/20191009032124.10541-23-david@fromorbit.com/

Well, it isn't just the radix tree tagging, but mostly the
infrastructure in iget that seems duplicates a lot of very delicate
code.

For the actual inactivation run: why don't we queue up the inodes
for deactivation directly that, that use the work_struct in the
inode to directly queue up the inode to the workqueue and let the
workqueue manage the details? That also means we can piggy back on
flush_work and flush_workqueue to force one or more entries out.

Again I'm not saying I know this is better, but this is something that
comes to my mind when reading the code.