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

Robin Murphy <[email protected]> Tue, 4 Aug 2026 16:23:45 +0100
Newsgroups dev.linux.lists.iommu,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 04/08/2026 3:17 pm, 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 :\

Right, but if we implement a general command-line option/module 
parameter/whatever with a variable that needs a default value for when 
it's not overridden, then it's even more trivial to initialise *that* 
default value based on further conditions as desired.

Plus implementing the more dynamic mechanism to begin with is arguably 
nicer than hard-coding a kdump special case in what is effectively the 
wrong place, since semantically what we really want to 
override/generalise are the max_n_shift initialisations in 
arm_smmu_device_hw_probe() itself.

Thanks,
Robin.

> So functionally I still think this patch is fine, though yes it points
> out more things in Nicolin's work too.
> 
> Jason