Re: [PATCH v2 3/8] iommu/arm-smmu-v3: Optimize range invalidation for latency

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Jul 07, 2026 at 11:45:40AM +0000, Mostafa Saleh wrote:
> > Calculate the smallest SCALE such that NUM can cover the range to minimize
> > over-invalidation. Always use a RIL command if RIL is possible working
> > around the spec limitations to form a valid one. If RIL is not possible
> > then do full invalidation.
> > 
> 
> That may be beneficial for servers, but I am not sure about other use
> cases, we already know that the invalidated entries are unmapped
> and not used. However, over invalidating might impact live DMA which
> would be bad for workloads sensitive to translation latency (as
> embedded cameras, displays for example). 

The isochronos stuff I've seen has a latency budget for translation
lookups and has to be tolerant of an occasional full walk.

Prior to RIL you had a much bigger issue, the cap on the range ment
you'd face a full invalidation from time to time if the domain is
being used for DMA while something ischronous is ongoing. Compared to
that a RIL over invalidation is not significant.

I have been talking to people about some formal isochronos support
that could do several things to try to manage the latency of DMA, it
would be reasonable to include some alternative RIL algorithm here if
that happens someday, and it is an issue.

But otherwise, I think we should leave it. Over invalidation is
consistent with how single works, and single has a long history in the
field so I don't think RIL is any worse.

> > At least one invalidation errata is avoided by 'always use RIL'.
> 
> Can you please clarify what that means?

Errata 3673557 requires using RIL if CONT is used otherwise there can
be stale entries

> > +static bool arm_smmu_cmdq_batch_add_single(struct arm_smmu_device *smmu,
> > +					   struct arm_smmu_cmdq_batch *cmds,
> > +					   struct arm_smmu_cmd *cmd,
> > +					   struct arm_smmu_tlbi *tlbi)
> > +{
> > +	unsigned long num_ops = tlbi->size / tlbi->iopte_granule;
> > +	unsigned long iova = tlbi->iova;
> > +	unsigned long i;
> > +
> > +	if (!num_ops || num_ops > 512)
> 
> Is there a reason that was added instead of keeping the old formula?

The original was based on address range as an imperfect proxy for
number of operations, here we can compute exactly the number of
operations given the required tg and level being targetted.

Under the PAGE_SIZE condition this is equivalent. Under
something like 2M huge pages this avoids falling back to full
invalidation in more cases.

Jason