From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: <will@kernel.org>, <robin.murphy@arm.com>, <joro@8bytes.org>,
<jean-philippe@linaro.org>, <miko.lenczewski@arm.com>,
<balbirs@nvidia.com>, <peterz@infradead.org>,
<smostafa@google.com>, <kevin.tian@intel.com>, <praan@google.com>,
<zhangzekun11@huawei.com>, <linux-arm-kernel@lists.infradead.org>,
<iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<patches@lists.linux.dev>
Subject: Re: [PATCH rfcv1 4/8] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array
Date: Tue, 26 Aug 2025 17:49:14 -0700 [thread overview]
Message-ID: <aK5WCnE/HTtdnLNv@Asurada-Nvidia> (raw)
In-Reply-To: <20250826195003.GA2151485@nvidia.com>
On Tue, Aug 26, 2025 at 04:50:03PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 13, 2025 at 06:25:35PM -0700, Nicolin Chen wrote:
> > +struct arm_smmu_invs *arm_smmu_invs_add(struct arm_smmu_invs *old_invs,
> > + struct arm_smmu_invs *add_invs)
> > +{
> > + size_t need = old_invs->num_invs + add_invs->num_invs;
> > + struct arm_smmu_invs *new_invs;
> > + size_t deletes = 0, i, j;
> > + u64 existed = 0;
> > +
> > + /* Max of add_invs->num_invs is 64 */
> > + if (WARN_ON(add_invs->num_invs > sizeof(existed) * 8))
> > + return ERR_PTR(-EINVAL);
>
> Since this is driven off of num_streams using a fixed bitmap doesn't
> seem great since I suppose the dt isn't limited to 64.
In the other patch, you noted that it's likely very rare to have
an ATS-supported device with multiple SIDs. Also given that this
function is called per device. So, 64 should be enough?
With that being said...
> Given how this is working now I think you can just add a new member to
> the struct:
>
> struct arm_smmu_inv {
> /* invalidation items */
> struct arm_smmu_device *smmu;
> u8 type;
> u8 size_opcode;
> u8 nsize_opcode;
> /* Temporary bits for add/del functions */
> u8 reuse:1;
> u8 todel:1;
>
> And use reuse as the temporary instead of the bitmap.
... I do like this reuse flag. I will give it a try.
> > + /* Count the trash entries to deletes */
> > + if (cur->todel) {
> > + WARN_ON_ONCE(refcount_read(&cur->users));
> > + deletes++;
> > + }
>
> Just do continue here.
>
> todel should only be used as a temporary. Use refcount_read() ==
> 0. Then you don't need a WARN either.
I did so until my last local pre-v1 version as I found it seems
cleaner to mark it using the todel. I'll try again and see how
it goes.
> > + /* Revert the todel marker for reuse */
> > + if (cur->todel) {
> > + cur->todel = false;
> > + deletes--;
>
> This wil blow up the refcount_inc() below because users is 0..
> There is no point in trying to optimize like this just discard the
> old entry and add a new one.
Oh right. refcount == 0 can't increase...
> > + unsigned int idx = add_invs->inv[j].id;
>
>
> Similar remarks for del, use users to set todel, don't expect it to be
> valid coming into the function.
OK.
Thanks
Nicolin
next prev parent reply other threads:[~2025-08-27 0:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 1:25 [PATCH rfcv1 0/8] iommu/arm-smmu-v3: Introduce an RCU-protected invalidation array Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 1/8] iommu/arm-smmu-v3: Clear cmds->num after arm_smmu_cmdq_batch_submit Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 2/8] iommu/arm-smmu-v3: Explicitly set smmu_domain->stage for SVA Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 3/8] iommu/arm-smmu-v3: Add an inline arm_smmu_domain_free() Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 4/8] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array Nicolin Chen
2025-08-26 19:50 ` Jason Gunthorpe
2025-08-27 0:49 ` Nicolin Chen [this message]
2025-08-27 16:48 ` Jason Gunthorpe
2025-08-27 17:19 ` Nicolin Chen
2025-08-28 12:37 ` Jason Gunthorpe
2025-08-27 20:00 ` Jason Gunthorpe
2025-09-06 8:16 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 5/8] iommu/arm-smmu-v3: Pre-allocate a per-master invalidation array Nicolin Chen
2025-08-26 19:56 ` Jason Gunthorpe
2025-09-06 7:45 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 6/8] iommu/arm-smmu-v3: Populate smmu_domain->invs when attaching masters Nicolin Chen
2025-08-27 18:21 ` Jason Gunthorpe
2025-09-06 7:52 ` Nicolin Chen
2025-09-06 8:20 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 7/8] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range() Nicolin Chen
2025-08-27 18:49 ` Jason Gunthorpe
2025-09-06 8:12 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 8/8] iommu/arm-smmu-v3: Perform per-domain invalidations using arm_smmu_invs Nicolin Chen
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=aK5WCnE/HTtdnLNv@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miko.lenczewski@arm.com \
--cc=patches@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=will@kernel.org \
--cc=zhangzekun11@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).