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

Nicolin Chen <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.ports.arm.kernel
Message-ID <anIjwUVvfWOb9xa4@Asurada-Nvidia>
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.

Thanks
Nicolin
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.