From: "Darrick J. Wong" <djwong@kernel.org>
To: Hans Holmberg <hans.holmberg@wdc.com>
Cc: linux-xfs@vger.kernel.org, Carlos Maiolino <cem@kernel.org>,
Dave Chinner <david@fromorbit.com>,
Christoph Hellwig <hch@lst.de>,
dlemoal@kernel.org, johannes.thumshirn@wdc.com
Subject: Re: [PATCH] xfs: always allocate the free zone with the lowest index
Date: Tue, 20 Jan 2026 07:53:29 -0800 [thread overview]
Message-ID: <20260120155329.GM15551@frogsfrogsfrogs> (raw)
In-Reply-To: <20260120085746.29980-1-hans.holmberg@wdc.com>
On Tue, Jan 20, 2026 at 09:57:46AM +0100, Hans Holmberg wrote:
> Zones in the beginning of the address space are typically mapped to
> higer bandwidth tracks on HDDs than those at the end of the address
> space. So, in stead of allocating zones "round robin" across the whole
> address space, always allocate the zone with the lowest index.
Does it make any difference if it's a zoned ssd? I'd imagine not, but I
wonder if there are any longer term side effects like lower-numbered
zones filling up and getting gc'd more often?
--D
> This increases average write bandwidth for overwrite workloads
> when less than the full capacity is being used. At ~50% utilization
> this improves bandwidth for a random file overwrite benchmark
> with 128MiB files and 256MiB zone capacity by 30%.
>
> Running the same benchmark with small 2-8 MiB files at 67% capacity
> shows no significant difference in performance. Due to heavy
> fragmentation the whole zone range is in use, greatly limiting the
> number of free zones with high bw.
>
> Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
> ---
>
> fs/xfs/xfs_zone_alloc.c | 47 +++++++++++++++--------------------------
> fs/xfs/xfs_zone_priv.h | 1 -
> 2 files changed, 17 insertions(+), 31 deletions(-)
>
> diff --git a/fs/xfs/xfs_zone_alloc.c b/fs/xfs/xfs_zone_alloc.c
> index bbcf21704ea0..d6c97026f733 100644
> --- a/fs/xfs/xfs_zone_alloc.c
> +++ b/fs/xfs/xfs_zone_alloc.c
> @@ -408,31 +408,6 @@ xfs_zone_free_blocks(
> return 0;
> }
>
> -static struct xfs_group *
> -xfs_find_free_zone(
> - struct xfs_mount *mp,
> - unsigned long start,
> - unsigned long end)
> -{
> - struct xfs_zone_info *zi = mp->m_zone_info;
> - XA_STATE (xas, &mp->m_groups[XG_TYPE_RTG].xa, start);
> - struct xfs_group *xg;
> -
> - xas_lock(&xas);
> - xas_for_each_marked(&xas, xg, end, XFS_RTG_FREE)
> - if (atomic_inc_not_zero(&xg->xg_active_ref))
> - goto found;
> - xas_unlock(&xas);
> - return NULL;
> -
> -found:
> - xas_clear_mark(&xas, XFS_RTG_FREE);
> - atomic_dec(&zi->zi_nr_free_zones);
> - zi->zi_free_zone_cursor = xg->xg_gno;
> - xas_unlock(&xas);
> - return xg;
> -}
> -
> static struct xfs_open_zone *
> xfs_init_open_zone(
> struct xfs_rtgroup *rtg,
> @@ -472,13 +447,25 @@ xfs_open_zone(
> bool is_gc)
> {
> struct xfs_zone_info *zi = mp->m_zone_info;
> + XA_STATE (xas, &mp->m_groups[XG_TYPE_RTG].xa, 0);
> struct xfs_group *xg;
>
> - xg = xfs_find_free_zone(mp, zi->zi_free_zone_cursor, ULONG_MAX);
> - if (!xg)
> - xg = xfs_find_free_zone(mp, 0, zi->zi_free_zone_cursor);
> - if (!xg)
> - return NULL;
> + /*
> + * Pick the free zone with lowest index. Zones in the beginning of the
> + * address space typically provides higher bandwidth than those at the
> + * end of the address space on HDDs.
> + */
> + xas_lock(&xas);
> + xas_for_each_marked(&xas, xg, ULONG_MAX, XFS_RTG_FREE)
> + if (atomic_inc_not_zero(&xg->xg_active_ref))
> + goto found;
> + xas_unlock(&xas);
> + return NULL;
> +
> +found:
> + xas_clear_mark(&xas, XFS_RTG_FREE);
> + atomic_dec(&zi->zi_nr_free_zones);
> + xas_unlock(&xas);
>
> set_current_state(TASK_RUNNING);
> return xfs_init_open_zone(to_rtg(xg), 0, write_hint, is_gc);
> diff --git a/fs/xfs/xfs_zone_priv.h b/fs/xfs/xfs_zone_priv.h
> index ce7f0e2f4598..8fbf9a52964e 100644
> --- a/fs/xfs/xfs_zone_priv.h
> +++ b/fs/xfs/xfs_zone_priv.h
> @@ -72,7 +72,6 @@ struct xfs_zone_info {
> /*
> * Free zone search cursor and number of free zones:
> */
> - unsigned long zi_free_zone_cursor;
> atomic_t zi_nr_free_zones;
>
> /*
> --
> 2.40.1
>
>
next prev parent reply other threads:[~2026-01-20 15:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 8:57 [PATCH] xfs: always allocate the free zone with the lowest index Hans Holmberg
2026-01-20 15:53 ` Darrick J. Wong [this message]
2026-01-21 7:16 ` Christoph Hellwig
2026-01-21 7:23 ` Hans Holmberg
2026-01-21 7:16 ` Christoph Hellwig
2026-01-21 12:24 ` Carlos Maiolino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260120155329.GM15551@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=cem@kernel.org \
--cc=david@fromorbit.com \
--cc=dlemoal@kernel.org \
--cc=hans.holmberg@wdc.com \
--cc=hch@lst.de \
--cc=johannes.thumshirn@wdc.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox