From: John Garry <john.garry@linux.dev>
To: Pankaj Raghav <pankaj.raghav@linux.dev>,
"Darrick J . Wong" <djwong@kernel.org>
Cc: Pankaj Raghav <p.raghav@samsung.com>,
cem@kernel.org, linux-xfs@vger.kernel.org,
John Garry <john.g.garry@oracle.com>,
gost.dev@samsung.com
Subject: Re: [PATCH] xfs: don't limit software atomic writes by the group alignment
Date: Fri, 2 Oct 2026 09:45:39 +0100 [thread overview]
Message-ID: <ecdac500-12ea-4a27-a8ef-b85fbfaef469@linux.dev> (raw)
In-Reply-To: <9723ca61-faed-412e-bef4-e6841393b8a8@linux.dev>
On 10/1/26 17:30, Pankaj Raghav wrote:
>>
>> ----->8-----
>>
>> --- a/fs/xfs/xfs_mount.c
>> +++ b/fs/xfs/xfs_mount.c
>> @@ -694,7 +694,7 @@ xfs_calc_group_awu_max(
>>
>> if (g->blocks == 0)
>> return 0;
>> - if (btp && btp->bt_awu_min > 0)
>> + if (btp && btp->bt_awu_max > mp->m_sb.sb_blocksize)
>> return max_pow_of_two_factor(g->blocks);
>> return rounddown_pow_of_two(g->blocks);
>> }
>>
>> -----8<-----
>>
>>
>> You are advocating something like this (to solve the issue below), right?
>>
>
> Hmm, this might fix the issue but I still don't understand why we have
> hardware atomics check while determining SW atomics limit. Am I missing
> something?
ok, I suppose that it (i.e. whether bt_awu_max > sb_blocksize) should
not determine CoW-based atomics limits, but it should determine HW
limits (in opt max).
>
>> note: that we still need to ensure that bt_awu_min <= sb_blocksize to
>> get HW atomics at all (so should keep a check for bt_awu_min in
>> xfs_calc_group_awu_max() or similar)
next prev parent reply other threads:[~2026-10-02 8:45 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 [this message]
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
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=ecdac500-12ea-4a27-a8ef-b85fbfaef469@linux.dev \
--to=john.garry@linux.dev \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=gost.dev@samsung.com \
--cc=john.g.garry@oracle.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.