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

[Jason Gunthorpe]

On Thu, Aug 13, 2026 at 03:12:03PM +0000, Mostafa Saleh wrote:
> > > 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?
> > 
> > I think it makes sense for a driver to indicate to the core code that
> > it needs isochronous and we can do more global things like change how
> > single works as well. Having an isochronous flag on the domain, for
> > example, would be a good overall direction.
> 
> But according to what? It makes sense to optimize server chips,
> but that should not cause over-invalidation regressions on other
> hardware.

The driver operating the device should know if it is putting an
isochronous DMA on to the device. It can make a function call to tell
the kernel it is doing this. Then we can make changes to accomodate
it. Change the invalidation logic, disable FQ, etc.

> > I'm inclined to leave this as is and let someone come with a specific
> > problematic HW, rather that try to badly guess without much
> > information if it might popssibly be a problem.
> 
> It's not really a guess, I mentioned some examples above, that I
> have seen problems of translation latencies on them.

I agree translation latencies are a worry, but there are alot of "ifs"
before this specific issue would become a real problem.

So, when I mean "specific problematic HW", I mean an actual system
that actually hits all the necessary preconditions for this specific
RIL logic to breaking.

And if there is HW that is so incredible sensitive then I strongly
feel we should have a formal API to declare and take robust steps to
make it work, not rely on a fragile patch work of "happens to work"
and special tunings.

> And why not the other way around:
> - Which uses cases can't handle few RIL commands?

It is latency effecting, we are seeing more server workloads want to
run with iommu=strict for security so the latency is a negative.

> - Why those drivers does not unmap memory with a granule/IOVA fitting
>   to RIL?

This is governed by the IOVA allocator, so it applies equally to
both. If the IOVA allocator uses power of 2 for all requests then RIL
over sizing isn't a problem.

> - Why those systems does not use FQ domains in the first place?

Do these embedded systems disable FQ because they break if FQ is used?

Wouldn't it be better if the kernel automatically did that instead of
having to tune for it in sysfs?

Jason