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

[Mostafa Saleh <smostafa@google.com>]

On Tue, Jul 07, 2026 at 09:10:58PM -0300, Jason Gunthorpe wrote:
> 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.

Sorry I lost track of this thread and I just saw v4.

In the mobile space, I haven't seen an SMMUv3 that does not support
RIL.

However, I have seen workloads that are really sensitive to translation
latency (display, camera...). And I'd be concerned about those
regressing.

There is a clear trade-off here as you mentioned with TLBI latency,
would it be make sense to make that behviour configurable from a
module param?

Also, looking at SMMUv2, it does not qualify single commands to
over invalidation (but it exposes and knob that is used by qcom
driver), so it is always accurate by default.

Thanks,
Mostafa