These patches cleans up the xfs mru code a bit and adds a cache for
keeping track of which zone an inode allocated data to last. Placing
file data in the same zone helps reduce write amplification.

Sending out as an RFC to get comments, specifically about the potential
mru lock contention when doing the lookup during allocation.

Can we do something better there?
I'll look into benchmarking the overhead, but any sugestions on how to
do this best would be helpful.

Christoph Hellwig (1):
  xfs: free the item in xfs_mru_cache_insert on failure

Hans Holmberg (1):
  xfs: add inode to zone caching for data placement

 fs/xfs/xfs_filestream.c |  15 ++----
 fs/xfs/xfs_mount.h      |   1 +
 fs/xfs/xfs_mru_cache.c  |  15 ++++--
 fs/xfs/xfs_zone_alloc.c | 109 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 126 insertions(+), 14 deletions(-)

-- 
2.34.1

On Wed, Apr 30, 2025 at 08:41:20AM +0000, Hans Holmberg wrote:
> Sending out as an RFC to get comments, specifically about the potential
> mru lock contention when doing the lookup during allocation.

I am a little worried about that.  The MRU cache is implemented right
now rotates the mru list on every lookup under a mru-cache wide lock,
which is bit of a performance nightmare.

I wonder if we can do some form of batched move between the mru buckets
that can reduce the locking and cacheline write impact.

But maybe it's worth to give this a try and work from performance reports
as needed.