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

[Will Deacon]

On Thu, Aug 13, 2026 at 03:01:02PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 13, 2026 at 06:25:59PM +0100, Robin Murphy wrote:
> > > > Yes, those exist, but again, they are already facing these problems if
> > > > running without RIL.
> > > 
> > > Yes, but my point is that those typically support RIL and that change
> > > regresses them.
> > 
> > Not even that - the main concern is over-invalidation of adjacent in-use
> > buffers due to rounding up; non-RIL absolutely does not have that issue and
> > never has.
> 
> It certainly does! SMMUv3 got an invalidate all path a while back
> because doing single for >> MB's of IOVA effectively soft lockups the
> system - especially with SVA.
> 
> We set the cut off at ~2M which matches when the CPU goes to
> invalidate all. That's 512 commands max of single TBLIs before we just
> dump the entire TLB. That's a huge over invalidation.
> 
> > Note that with RIL, even precise invalidation should only actually need at
> > most two commands (excepting absurd off-the-scale sizes) - the trick is to
> > consider that they can overlap.
> 
> Oh that's really interesting, I never thought about doing it like
> that. It is way better than the algorithm that is there right now.
> 
> Let me try it, it seems like it would make everyone happy.

I was planning to reply yesterday saying something like "Robin previously
mentioned this one neat trick...", but I didn't get round to it. So yeah,
if we can implement that, I think we can have one range invalidation
algorithm to rule them all.

Will