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 garbage collection overhead,
and with this patch we add support per-file co-location for random
writes.

While I was initially concerned by adding overhead to the allocation
path, the cache actually reduces it as as we avoid going through the
zone allocation algorithm for every random write.

When I run a fio workload with 16 writers to different files in
parallel, bs=8k, iodepth=4, size=1G, I get these throughputs:

baseline	with_cache
774 MB/s	858 MB/s (+11%)

(averaged over three runs ech on a nullblk device)

I see similar, figures when benchmarking on a zns nvme drive (+17%).

No updates in the code since the RFC:
https://www.spinics.net/lists/linux-xfs/msg98889.html

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, 14 May 2025 10:50:36 +0000, Hans Holmberg wrote:
> 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 garbage collection overhead,
> and with this patch we add support per-file co-location for random
> writes.
> 
> While I was initially concerned by adding overhead to the allocation
> path, the cache actually reduces it as as we avoid going through the
> zone allocation algorithm for every random write.
> 
> [...]

Applied to for-next, thanks!

[1/2] xfs: free the item in xfs_mru_cache_insert on failure
      commit: 70b95cb86513d7f6d084ddc8e961a1cab9022e14
[2/2] xfs: add inode to zone caching for data placement
      commit: f3e2e53823b98d55da46ea72d32ac18bd7709c33

Best regards,
-- 
Carlos Maiolino <cem@kernel.org>

On Wed, May 14, 2025 at 10:50:36AM +0000, Hans Holmberg wrote:
> While I was initially concerned by adding overhead to the allocation
> path, the cache actually reduces it as as we avoid going through the
> zone allocation algorithm for every random write.
> 
> When I run a fio workload with 16 writers to different files in
> parallel, bs=8k, iodepth=4, size=1G, I get these throughputs:
> 
> baseline	with_cache
> 774 MB/s	858 MB/s (+11%)
> 
> (averaged over three runs ech on a nullblk device)
> 
> I see similar, figures when benchmarking on a zns nvme drive (+17%).

Very nice!

These should probably go into the commit message for patch 2 so they
are recorded.  Carlos, is that something you can do when applying?

On Wed, May 14, 2025 at 03:00:14PM +0200, hch wrote:
> On Wed, May 14, 2025 at 10:50:36AM +0000, Hans Holmberg wrote:
> > While I was initially concerned by adding overhead to the allocation
> > path, the cache actually reduces it as as we avoid going through the
> > zone allocation algorithm for every random write.
> >
> > When I run a fio workload with 16 writers to different files in
> > parallel, bs=8k, iodepth=4, size=1G, I get these throughputs:
> >
> > baseline	with_cache
> > 774 MB/s	858 MB/s (+11%)
> >
> > (averaged over three runs ech on a nullblk device)
> >
> > I see similar, figures when benchmarking on a zns nvme drive (+17%).
> 
> Very nice!
> 
> These should probably go into the commit message for patch 2 so they
> are recorded.  Carlos, is that something you can do when applying?
> 

Nvm, I just noticed you as the author. I'll review it

On Wed, May 14, 2025 at 03:00:14PM +0200, hch wrote:
> On Wed, May 14, 2025 at 10:50:36AM +0000, Hans Holmberg wrote:
> > While I was initially concerned by adding overhead to the allocation
> > path, the cache actually reduces it as as we avoid going through the
> > zone allocation algorithm for every random write.
> >
> > When I run a fio workload with 16 writers to different files in
> > parallel, bs=8k, iodepth=4, size=1G, I get these throughputs:
> >
> > baseline	with_cache
> > 774 MB/s	858 MB/s (+11%)
> >
> > (averaged over three runs ech on a nullblk device)
> >
> > I see similar, figures when benchmarking on a zns nvme drive (+17%).
> 
> Very nice!
> 
> These should probably go into the commit message for patch 2 so they
> are recorded.  Carlos, is that something you can do when applying?
> 
Absolutely. Could you RwB patch 1? I just got your RwB on patch 2.

I'll add this to the tree today, I need to do another rebase anyway.

On Wed, May 14, 2025 at 03:51:54PM +0200, Carlos Maiolino wrote:
> Absolutely. Could you RwB patch 1? I just got your RwB on patch 2.

I wrote it, so I can't review it.  But Hans has reviewed it as part
of passing it own, but that's designated by a signoff.

I'd be happy to wait for another review, though.