Re: [PATCH v7 10/11] iommu/arm-smmu-v3: Invoke pm_runtime before hw access

[Pranjal Shrivastava <praan@google.com>]

On Wed, Jun 03, 2026 at 03:18:32PM -0700, Daniel Mentz wrote:
> On Thu, May 28, 2026 at 2:46 PM Pranjal Shrivastava <praan@google.com> wrote:
> >
> > On Thu, May 28, 2026 at 01:28:15PM -0700, Nicolin Chen wrote:
> > > On Wed, May 27, 2026 at 10:14:06PM +0000, Pranjal Shrivastava wrote:
> > > > TLB and CFG invalidations are
> > > > elided if the SMMU is suspended by observing the CMDQ_PROD_STOP_FLAG via
> > > > the arm_smmu_can_elide() helper.
> > >
> > > All the arm_smmu_can_elide() call sites here would eventually elide
> > > the commands in arm_smmu_cmdq_issue_cmdlist() that is already gated
> > > by CMDQ_PROD_STOP_FLAG? It doesn't seem necessary to gate again?
> >
> > While issue_cmdlist() would eventually elide these commands, the
> > can_elide() check is necessary to return early during suspension.
> >
> > This avoids unnecessary stack allocation, cmd building, and spinlock
> > contention on the cmdq->lock for threads that are anyway about to be
> > elided.
> >
> > By dropping these requests immediately, we significantly reduce cacheline
> > bouncing and contention during unmap storms. Furthermore, the early check
> > also allows us to specifically trigger the WARN_ON_ONCE() for broken
> > devlinks.
> 
> Hi Pranjal,
> 
> Have you observed unmap storms in a real-world use case, or is this a
> preemptive optimization? I would not expect a high rate of map/unmap
> operations while the SMMU is suspended. If a client device calls
> iommu_map/iommu_unmap (directly or indirectly), it suggests the client
> device is RPM_ACTIVE, meaning the SMMU should be active as well.
> 
> I am in favor of removing arm_smmu_can_elide().

I saw some with DMA_FQ (fq_timer does batched async invalidations) but
the early ellision doesn't really help with perf which I agreed to in my
reply to Nicolin as well. 

The early checks were dropped in v8 (except for invs_array and for the 
WARN_ON in inv_master).

Thanks,
Praan