public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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
> 
> 

  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