From: Will Deacon <will@kernel.org>
To: Kiryl Shutsemau <kirill@shutemov.name>
Cc: Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>,
Thierry Reding <thierry.reding@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Nicolin Chen <nicolinc@nvidia.com>,
Breno Leitao <leitao@debian.org>,
"Kiryl Shutsemau (Meta)" <kas@kernel.org>,
Krishna Reddy <vdumpa@nvidia.com>,
Pranjal Shrivastava <praan@google.com>,
Mostafa Saleh <smostafa@google.com>,
Ashish Mhetre <amhetre@nvidia.com>,
Shameer Kolothum <skolothumtho@nvidia.com>,
Yuanhe Shu <xiangzao@linux.alibaba.com>,
Kyle McMartin <jkkm@meta.com>, Usama Arif <usama.arif@linux.dev>,
kernel-team@meta.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 0/2] iommu/arm-smmu-v3: Make the queue depths tunable, and shrink them in a kdump kernel
Date: Fri, 2 Oct 2026 16:39:53 +0100 [thread overview]
Message-ID: <ar_QSdV44YzQQ6Yx@willie-the-truck> (raw)
In-Reply-To: <20260925141532.1274962-1-kirill@shutemov.name>
On Fri, Sep 25, 2026 at 03:15:28PM +0100, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> The queues are sized from the IDR1 maxima and allocated at probe, costing
> megabytes per queue per SMMU instance. A kdump capture kernel pays that out
> of a small crashkernel reservation, for queues it barely uses and two of
> which it switches off anyway.
>
> Patch 1 adds a cmdq_max_n_shift module parameter, decided in a per-queue
> helper and floored at one page. Patch 2 has a kdump kernel size all three
> queues at one page through the same helper. The parameter does not apply
> there.
>
> Yuanhe Shu tested v6 on an arm64 server with six SMMUv3 instances, 64K
> pages and a 512 MiB crashkernel reservation. Without the series the queues
> took 192 MiB and the capture kernel OOMed before makedumpfile ran. With it
> they take about 1 MiB and the vmcore is saved.
>
> Measured per instance under QEMU on -M virt,iommu=smmuv3 with the virtio
> devices behind the SMMU, the capture kernel identified by elfcorehdr= on
> the command line:
>
> 4K page 64K page
> cmdq 1 MB -> 4 KB 8 MB -> 64 KB
> evtq 1 MB -> 4 KB 16 MB -> 64 KB
>
> cmdq_max_n_shift moves the command queue alone outside kdump and is
> ignored inside it; zero gives one page. QEMU exposes no PRI queue, which
> takes the same path. No CMD_SYNC timeout, GERROR or context fault in any
> run. Build-tested across 4K/16K/64K, TEGRA241_CMDQV=n, CRASH_DUMP=n and
> ARM_SMMU_V3=m, every commit warning-free.
>
> v7:
> - Flatten the depth helper as Jason suggested: floor the limit, then min
> with the hardware maximum; callers pass their alignment cap as the
> limit.
> - Initialise cmdq_max_n_shift to CMDQ_MAX_SZ_SHIFT, so zero is no longer
> the "default" sentinel; it asks for the smallest queue, one page.
> - A kdump kernel always gets one page; cmdq_max_n_shift no longer
> overrides it.
> - Tags: Breno's and Jason's Reviewed-by on patch 1, Jason's Reviewed-by
> and Yuanhe's Tested-by on patch 2.
Ah, sorry, I missed that you'd already sent a v7! As I said on v6, I don't
have a particularly strong opinion on the naming, so given that Jason is
happy with the logic, I'll just apply this now as-is.
Cheers,
Will
next prev parent reply other threads:[~2026-10-02 15:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 14:15 [PATCH v7 0/2] iommu/arm-smmu-v3: Make the queue depths tunable, and shrink them in a kdump kernel Kiryl Shutsemau
2026-09-25 14:15 ` [PATCH v7 1/2] iommu/arm-smmu-v3: Add a cmdq_max_n_shift module parameter Kiryl Shutsemau
2026-09-25 19:02 ` Nicolin Chen
2026-09-25 14:15 ` [PATCH v7 2/2] iommu/arm-smmu-v3: Default queue depths to one page in a kdump kernel Kiryl Shutsemau
2026-09-25 15:36 ` Breno Leitao
2026-09-25 19:04 ` Nicolin Chen
2026-09-25 22:48 ` [PATCH v7 0/2] iommu/arm-smmu-v3: Make the queue depths tunable, and shrink them " Jason Gunthorpe
2026-10-02 15:39 ` Will Deacon [this message]
2026-10-02 16:46 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ar_QSdV44YzQQ6Yx@willie-the-truck \
--to=will@kernel.org \
--cc=amhetre@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jkkm@meta.com \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=kirill@shutemov.name \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=skolothumtho@nvidia.com \
--cc=smostafa@google.com \
--cc=thierry.reding@kernel.org \
--cc=usama.arif@linux.dev \
--cc=vdumpa@nvidia.com \
--cc=xiangzao@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox