Re: [PATCH V2 00/26] mm, xfs: non-blocking inode reclaim

Josef Bacik
2019-10-11T19:03:13Z

On Wed, Oct 09, 2019 at 02:20:58PM +1100, Dave Chinner wrote:
> Hi folks,
>
> This is the second version of the RFC I originally posted here:
>
> https://lore.kernel.org/linux-xfs/20190801021752.4986-1-david@fromorbit.com/
>
> The original description of the patchset is below, the issues and
> approach to solving them has not changed. THere is some
> restructuring of the patch set - the first few patches are all the
> XFS fixes that can be merged regardless of the rest of the patchset,
> but the non-blocking reclaim is somewhat dependent of them for
> correct behaviour. The second set of patches are the shrinker
> infrastructure changes needed for the shrinkers to feed back
> reclaim progress to the main reclaim instructure and act on the
> feedback. The last set of patches are the XFS changes needed to
> convert inode reclaim over to a non-blocking, IO-less algorithm.
>

I looked through the MM patches and other than the congestion thing they look
reasonable. I think I can probably use this stuff to drop the use of the btree
inode. However I'm wondering if it would be a good idea to add an explicit
backoff thing for heavy metadata dirty'ing operations. Btrfs generates a lot
more dirty metadata than most, partly why my attempt to deal with this was tied
to using balance dirty pages since it already has all of the backoff logic.

Perhaps an explict balance_dirty_metadata() that we put after all metadata
operations so we have a good way to throttle dirtiers when we aren't able to
keep up? Just a thought, based on my previous experiences trying to tackle this
issue for btrfs, what you've done already may be enough to address these
concerns. Thanks,

Josef