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

[Jason Gunthorpe <jgg@nvidia.com>]

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.

IDK that anyone wants commandline tunables, but it doesn't seem like a
big task

Jason