All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@linux.dev>
To: "Pankaj Raghav (Samsung)" <pankaj.raghav@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: Tue, 6 Oct 2026 08:06:31 +0100	[thread overview]
Message-ID: <ad7d42d3-114e-4506-89c3-9d60d1bdf659@linux.dev> (raw)
In-Reply-To: <asOpaPuHF072GJwt@quentin>

On 10/5/26 17:24, Pankaj Raghav (Samsung) wrote:
>>> 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?
> 

I'm not sure. Darrick may be able to give a good suggestion.

>>> +
>>>    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_get_atomic_write_max() does still have a 
xfs_inode_can_hw_atomic_write() call.

It just seems a bit awkward that xfs_get_atomic_write_max_opt() calls 
xfs_get_atomic_write_max(), when it should be able to do the full 
calculation itself.

This is not a deal deal which I am mentioning.

> 
>>
>>> +	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.
> 

ok, fine

BTW, maybe call the variable max_opt, and not just opt.


      reply	other threads:[~2026-10-06  7:06 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)
2026-10-06  7:06     ` John Garry [this message]

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=ad7d42d3-114e-4506-89c3-9d60d1bdf659@linux.dev \
    --to=john.garry@linux.dev \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=gost.dev@samsung.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=p.raghav@samsung.com \
    --cc=pankaj.raghav@linux.dev \
    /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.