Re: [PATCH v3] iommu/arm-smmu-v3: Shrink command/event/PRI queues in kdump kernel

[Will Deacon <will@kernel.org>]

On Tue, Aug 04, 2026 at 10:39:13AM -0700, Nicolin Chen wrote:
> On Tue, Aug 04, 2026 at 01:59:05PM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 04, 2026 at 09:45:01AM -0700, Nicolin Chen wrote:
> > > On Tue, Aug 04, 2026 at 01:19:18PM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Aug 04, 2026 at 09:04:32AM -0700, Nicolin Chen wrote:
> > > > > On Tue, Aug 04, 2026 at 11:17:04AM -0300, Jason Gunthorpe wrote:
> > > > > > On Tue, Aug 04, 2026 at 03:02:46PM +0100, Will Deacon wrote:
> > > > > > > > Would skipping their allocation when is_kdump_kernel() be acceptable on
> > > > > > > > its own, or would you rather see it done differently?
> > > > > > > 
> > > > > > > With Nicolin's patch, we can just avoid allocating the priq and the evtq
> > > > > > > entirely in the kdump case. We can then add a cmdline option to control
> > > > > > > the maximum size of the cmdq, which is useful regardless of kdump.
> > > > > > 
> > > > > > I would still prefer kdump do this re-sizing automatically, even if we
> > > > > > do add a commandline. It makes it easire to deploy than having to know
> > > > > > secret command lines :\
> > > > > > 
> > > > > > So functionally I still think this patch is fine, though yes it points
> > > > > > out more things in Nicolin's work too.
> > > > > 
> > > > > I will send a v10 of mine, to skip the EVTQ/PRIQ allocations.
> > > > 
> > > > I think Robin's point is to structure the v10 so you introduce a bunch
> > > > of tunables, including something like 0 size to disable a feature.
> > > >
> > > > Then have kdump default those tunables to the right thing
> > > 
> > > But in kdump, EVTQ/PRIQ are disabled, so my series should have
> > > skipped their allocations regardless of the tunables.
> > > 
> > > So, I think the tunables can be done in a separate series. And
> > > its use case might not be confined to kdump?
> > 
> > I think the ask is to do the tunables first and change your series to
> > default the tunables instead of doing direct kdump overrides.
> 
> You mean the driver can override the tunables to 0 in kdump mode,
> right?
> 
> Well, we are skipping a lot of things in kdump mode already; it's
> a very small change to skip EVTQ/PRIQ even without the tunables.
> 
> If Will prefers this merging sequence, I wouldn't mind changing my
> series to overriding the tunables.

I was thinking that the tunable would only apply to the cmdq. We can extend
it later if necessary, but since we're not going to enable the evtq/priq
in kdump mode at all, I don't think we need tunables for those atm.

I probably wouldn't make a size of 0 disable the queue, either. Have a
minimum size of a page or something like that.

Will