All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: brauner@kernel.org, hch@lst.de, dgc@kernel.org, jack@suse.cz,
	cem@kernel.org, axboe@kernel.dk, kbusch@kernel.org,
	ritesh.list@gmail.com, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
	gost.dev@samsung.com, Anuj Gupta <anuj20.g@samsung.com>
Subject: Re: [PATCH v4 4/6] xfs: generic AG set based steering
Date: Mon, 20 Jul 2026 20:20:27 -0700	[thread overview]
Message-ID: <20260721032027.GW7380@frogsfrogsfrogs> (raw)
In-Reply-To: <20260717125538.508925-5-joshi.k@samsung.com>

On Fri, Jul 17, 2026 at 06:25:36PM +0530, Kanchan Joshi wrote:
> Improve allocator concurrency and reduce interleaving by introducing
> fixed sized AG set.
> Use low bits of the inode as a hash to select AG within the AG set.
> Overall, a file will try to use the same AG (and contiguity is maintained),
> but multiple files will be spread across all AGs in the target AG set.
> 
> Suggested-by: Dave Chinner <dgc@kernel.org>
> Signed-off-by: Kanchan Joshi <joshi.k@samsung.com>
> Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
> ---
>  fs/xfs/libxfs/xfs_bmap.c | 38 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
> index d64defeda645..fd1a3aa4ad3f 100644
> --- a/fs/xfs/libxfs/xfs_bmap.c
> +++ b/fs/xfs/libxfs/xfs_bmap.c
> @@ -3192,6 +3192,36 @@ xfs_bmap_select_minlen(
>  	return args->maxlen;
>  }
>  
> +#define	GENERIC_AG_SET_SZ	(2)

What does this define?

> +
> +static inline xfs_agnumber_t
> +xfs_default_ag_set_size(
> +	struct xfs_inode	*ip)
> +{
> +	struct xfs_mount	*mp = ip->i_mount;
> +
> +	return min_t(xfs_agnumber_t, GENERIC_AG_SET_SZ, mp->m_sb.sb_agcount);

Because I'm not sure what it means on a single-AG filesystem.

> +}
> +
> +static xfs_agnumber_t
> +xfs_ag_to_ag_set(
> +	struct xfs_bmalloca	*ap,
> +	xfs_agnumber_t		base_agno)
> +{
> +	struct xfs_inode	*ip = ap->ip;
> +	struct xfs_mount	*mp = ip->i_mount;
> +	xfs_agnumber_t		set_size;
> +
> +	/* Apply fanning only for regular file data */
> +	if (!(ap->datatype & XFS_ALLOC_USERDATA))
> +		return base_agno;
> +
> +	set_size = xfs_default_ag_set_size(ip);
> +	/* Fan out within the AG set using low bits of the inode */
> +	return (base_agno + (XFS_INO_TO_AGINO(mp, I_INO(ip)) % set_size)) %
> +		mp->m_sb.sb_agcount;
> +}
> +
>  static int
>  xfs_bmap_btalloc_select_lengths(
>  	struct xfs_bmalloca	*ap,
> @@ -3587,8 +3617,16 @@ xfs_bmap_btalloc_best_length(
>  {
>  	xfs_extlen_t		blen = 0;
>  	int			error;
> +	xfs_agnumber_t		target_ag, start_ag;
>  
>  	ap->blkno = XFS_INODE_TO_FSB(ap->ip);
> +
> +	/* fan out initial AG across the generic AG set */
> +	start_ag = XFS_FSB_TO_AGNO(args->mp, ap->blkno);
> +	target_ag = xfs_ag_to_ag_set(ap, start_ag);
> +	if (target_ag != start_ag)
> +		ap->blkno = XFS_AGB_TO_FSB(args->mp, target_ag, 0);

/me wonders, if xfs_bmap_rtalloc looked at ap->blkno for a hint the way
that the data device allocator does, then would it be trivial to have
write streams on the rt device too?

I guess the tricky part would be figuring out what to do if you ever
want to switch a file between rt and data devices -- presumably you'd
just reset the write stream id to the default, but I guess you could
reject such a switch if the id had been set explicitly.

--D

> +
>  	if (!xfs_bmap_adjacent(ap))
>  		ap->eof = false;
>  
> -- 
> 2.25.1
> 
> 

  reply	other threads:[~2026-07-21  3:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260717125624epcas5p3fefc5b8ff274260bf8fb2f1b225b4f9a@epcas5p3.samsung.com>
2026-07-17 12:55 ` [PATCH v4 0/6] xfs write streams Kanchan Joshi
2026-07-17 12:55   ` [PATCH v4 1/6] fs: add write-stream management ioctls Kanchan Joshi
2026-07-21  3:03     ` Darrick J. Wong
2026-07-30 14:52       ` Kanchan Joshi
2026-07-30 17:22         ` Darrick J. Wong
2026-07-31  8:15           ` Kanchan Joshi
2026-07-17 12:55   ` [PATCH v4 2/6] iomap: introduce and propagate write_stream Kanchan Joshi
2026-07-17 12:55   ` [PATCH v4 3/6] xfs: implement write-stream management support Kanchan Joshi
2026-07-21  3:08     ` Darrick J. Wong
2026-07-31  8:03       ` Kanchan Joshi
2026-07-17 12:55   ` [PATCH v4 4/6] xfs: generic AG set based steering Kanchan Joshi
2026-07-21  3:20     ` Darrick J. Wong [this message]
2026-07-24 14:57       ` Kanchan Joshi
2026-07-17 12:55   ` [PATCH v4 5/6] xfs: write stream based AG placement Kanchan Joshi
2026-07-17 12:55   ` [PATCH v4 6/6] xfs: introduce software write streams Kanchan Joshi

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=20260721032027.GW7380@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=anuj20.g@samsung.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=dgc@kernel.org \
    --cc=gost.dev@samsung.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=joshi.k@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=ritesh.list@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.