Re: [LSF/MM/BPF TOPIC] Filesystem inode reclaim

[Christoph Hellwig <hch@infradead.org>]

I think a patch is more useful than a discussion here, that idea has been
voiced multiple times, and effecticely implemented in XFS.

Trying to lift the XFS logic into the VFS and finding other consumers
for it would be very helpful.

> 1) Filesystems will be required to mark inodes that have non-trivial
> cleanup work to do on reclaim with an inode flag I_RECLAIM_HARD (or
> whatever :)). Usually I expect this to happen on first inode modification
> or so. This will require some per-fs work but it shouldn't be that
> difficult and filesystems can be adapted one-by-one as they decide to
> address these warnings from reclaim.

I think otherwise we call this dirty :)

> 2) Inodes without I_RECLAIM_HARD will be reclaimed as usual directly from
> kswapd / direct reclaim. I'm keeping this variant of inode reclaim for
> performance reasons. I expect this to be a significant portion of inodes
> on average and in particular for some workloads which scan a lot of inodes
> (find through the whole fs or similar) the efficiency of inode reclaim is
> one of the determining factors for their performance.

Yes, in most file systems most inodes are clean.

> There's also a simpler approach to this problem but with more radical
> changes to behavior. For example getting rid of inode LRU completely -
> inodes without dentries referencing them anymore should be rare and it
> isn't very useful to cache them. So we can always drop inodes on last
> iput() (as we currently do for example for unlinked inodes). But I have a
> nagging feeling that somebody is depending on inode LRU somewhere - I'd
> like poll the collective knowledge of what could possibly go wrong here :)

I've heard this theory multiple times, but we really need to valide that
we don't need the LRU.  It also doesn't really solve the above problem,
as we still would not want to perform the expensive inode inactivation
work inline with the last dput.

So while this might be worth investigating, please keept it separate.