All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pankaj Raghav (Samsung)" <pankaj.raghav@linux.dev>
To: John Garry <john.garry@linux.dev>
Cc: Pankaj Raghav <p.raghav@samsung.com>,
	cem@kernel.org,  linux-xfs@vger.kernel.org,
	"Darrick J . Wong" <djwong@kernel.org>,
	gost.dev@samsung.com
Subject: Re: [PATCH] xfs: don't limit software atomic writes by the group alignment
Date: Mon, 5 Oct 2026 18:24:48 +0200	[thread overview]
Message-ID: <asOpaPuHF072GJwt@quentin> (raw)
In-Reply-To: <8d9babb0-5d36-427d-b4a2-5a3e9664a796@linux.dev>

> > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
> > index d1306e723899..8c8b14f94ede 100644
> > --- a/fs/xfs/xfs_iops.c
> > +++ b/fs/xfs/xfs_iops.c
> > @@ -620,6 +620,12 @@ xfs_get_atomic_write_min(
> >   	return 0;
> >   }
> > +static inline enum xfs_group_type
> > +xfs_inode_group_type(struct xfs_inode *ip)
> > +{
> > +	return XFS_IS_REALTIME_INODE(ip) ? XG_TYPE_RTG : XG_TYPE_AG;
> > +}
> 
> would this be better is a common location (so that it could be reused)?
> 

Probably to xfs_mount.h?

> > +
> >   unsigned int
> >   xfs_get_atomic_write_max(
> >   	struct xfs_inode	*ip)
> > @@ -642,19 +648,20 @@ xfs_get_atomic_write_max(
> >   	 * then advertise a maximum size of whatever we can complete through
> >   	 * that means.  Hardware support is reported via max_opt, not here.
> >   	 */
> > -	if (XFS_IS_REALTIME_INODE(ip))
> > -		return XFS_FSB_TO_B(mp, mp->m_groups[XG_TYPE_RTG].awu_max);
> > -	return XFS_FSB_TO_B(mp, mp->m_groups[XG_TYPE_AG].awu_max);
> > +	return XFS_FSB_TO_B(mp, mp->m_groups[xfs_inode_group_type(ip)].awu_max);
> >   }
> >   unsigned int
> >   xfs_get_atomic_write_max_opt(
> >   	struct xfs_inode	*ip)
> >   {
> > +	struct xfs_mount	*mp = ip->i_mount;
> >   	unsigned int		awu_max = xfs_get_atomic_write_max(ip);
> 
> xfs_get_atomic_write_max() value is calculated based on HW atomic support. I
> am wondering if we should add a function to just give the max CoW-based
> atomic, and have it called here and from xfs_get_atomic_write_max(). Not a
> big deal, though.

Could you elaborate this comment?

I do remove any HW dependency in xfs_get_atomic_write_max() calculation
as a part of this patch.

> 
> > +	xfs_extlen_t		align_max_fsb;
> > +	unsigned int		opt;
> >   	/* if the max is 1x block, then just keep behaviour that opt is 0 */
> > -	if (awu_max <= ip->i_mount->m_sb.sb_blocksize)
> > +	if (awu_max <= mp->m_sb.sb_blocksize)
> >   		return 0;
> >   	/*
> > @@ -663,7 +670,17 @@ xfs_get_atomic_write_max_opt(
> >   	 * less than our out of place write limit, but we don't want to exceed
> >   	 * the awu_max.
> >   	 */
> > -	return min(awu_max, xfs_inode_buftarg(ip)->bt_awu_max);
> > +	opt = min(awu_max, xfs_inode_buftarg(ip)->bt_awu_max);
> > +
> > +	/*
> > +	 * REQ_ATOMIC writes also have to be naturally aligned on disk, so we
> > +	 * cannot promise more than the largest extent that the allocator is
> > +	 * able to align within a group.
> > +	 */
> > +	align_max_fsb = xfs_calc_group_awu_align_max(mp,
> > +						xfs_inode_group_type(ip));
> > +
> > +	return min_t(xfs_fsize_t, opt, XFS_FSB_TO_B(mp, align_max_fsb));
> 
> unsigned int? But is there a possibility that the value in XFS_FSB_TO_B(mp,
> align_max_fsb) can exceed an unsigned int?

We are limited by `opt` length which is an unsigned int. I do use
min_t(xfs_fsize_t, ..) for calculation to avoid any truncation error.

-- 
Pankaj

  reply	other threads:[~2026-10-05 16:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25 10:36 [PATCH] xfs: don't limit software atomic writes by the group alignment Pankaj Raghav
2026-09-25 11:44 ` John Garry
2026-09-29  7:17   ` Pankaj Raghav
2026-09-29 14:47     ` John Garry
2026-09-30  5:10       ` Pankaj Raghav (Samsung)
2026-09-30  8:42         ` John Garry
2026-09-30 12:27           ` Pankaj Raghav
2026-09-30 12:48             ` John Garry
2026-10-01 16:30               ` Pankaj Raghav
2026-10-02  8:45                 ` John Garry
2026-10-02 11:24                   ` Pankaj Raghav
2026-09-29 16:40     ` Darrick J. Wong
2026-09-29 20:42       ` Darrick J. Wong
2026-09-30  8:48         ` Pankaj Raghav (Samsung)
2026-10-07 17:43           ` Darrick J. Wong
2026-10-05 11:02 ` John Garry
2026-10-05 11:02 ` John Garry
2026-10-05 16:24   ` Pankaj Raghav (Samsung) [this message]
2026-10-06  7:06     ` John Garry

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=asOpaPuHF072GJwt@quentin \
    --to=pankaj.raghav@linux.dev \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=gost.dev@samsung.com \
    --cc=john.garry@linux.dev \
    --cc=linux-xfs@vger.kernel.org \
    --cc=p.raghav@samsung.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.