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

Daniel Mentz danielmentz at google.com
Sun Jun 7 13:17:39 PDT 2026


On Thu, Jun 4, 2026 at 12:18 AM Pranjal Shrivastava <praan at google.com> wrote:
>
> 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 at 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).

Hi Pranjal,

Please correct me if I'm wrong, but in v8, I can see a call to
arm_smmu_cmdq_can_elide() at the very beginning of
arm_smmu_domain_inv_range(). Isn't this the path every iommu_unmap
goes through?



More information about the linux-arm-kernel mailing list