summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorKiryl Shutsemau (Meta) <kas@kernel.org>2026-09-25 15:15:30 +0100
committerWill Deacon <will@kernel.org>2026-10-02 15:42:41 +0000
commit3f9fa6b9520d69c0fd400b0c260320c0a8a1500c (patch)
tree1baee1748607e3266c614c1ac68121bdad16eea3 /tools/perf/scripts/python/stackcollapse.py
parentc9b493a312f3f5f92f9bb5613b0ad78eb4d2a1da (diff)
iommu/arm-smmu-v3: Default queue depths to one page in a kdump kernel
All three queues are sized from the maxima the hardware advertises in IDR1 and allocated at probe, up to 4 MB each on a 4K-page kernel. The capture kernel already disables two of them: arm_smmu_device_reset() drops CR0_EVTQEN and CR0_PRIQEN. It still allocates both at full size. A kdump capture kernel runs from a small crashkernel reservation, and every SMMUv3 instance pays that cost again, up to 12 MB apiece. It goes to queues that either serve the handful of devices used to save the dump or are switched off outright, and it is memory the dump itself needs. Size all three queues at one page worth of entries when is_kdump_kernel(). The queues carry commands and fault records rather than DMA data, so dump throughput is unaffected. A shallower command queue only bounds how many commands may be in flight before a sync, which does not matter for the few devices that save the dump. The cmdq_max_n_shift parameter therefore does not apply in a capture kernel. Suggested-by: Kyle McMartin <jkkm@meta.com> Assisted-by: LLM Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Yuanhe Shu <xiangzao@linux.alibaba.com> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Breno Leitao <leitao@debian.org> Signed-off-by: Will Deacon <will@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions