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

[Jason Gunthorpe <jgg@nvidia.com>]

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.

> Conversely though, if we really did have a demonstrable need to minimise the
> number of commands issued then we should probably also not bother with the
> TTL hint nor splitting leaf ranges from non-leaf, such that we can gather
> pretty much any unmap into a single command.

That is what I am doing. The series converting to iommupt also changes
to use iommupt style gathers which default to combining everything
into one gather.

One gather maps to one tlbi in this series and it turns into one
RIL. The hints/etc are used if the gather happens to be compatible,
otherwise the single RIL is still pushed un-hinted.

> This is probably something we'll end up wanting some kind of tunable
> behaviour for, given that SMMUv3 hardware is going to be spanning an
> increasingly wide range of use-cases with increasingly opposing requirements
> - it's certainly more than just "hypervisor or not". For now, though, I'm
> also not buying a dubious latency argument based on apparently no real-world
> data other than "I think"...

We have data already showing that large numbers of invalidation
commands cause soft lockups, and we had to fix SMMU for this.

This is tied into the SVA path remember, latency directly effects mm
application benchmarks and we have been consistently working toward
bounding and reducing SVA invalidation latency. We actually did some
studies recently and invalidation latency had a major impact on real
application metrics. We did not build HW vCMDQ support to reduce
invalidation latences in VMs for no reason. It is not "I think".

Thanks,
Jason