public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: leo.jiang1224@foxmail.com, will@kernel.org
Cc: joro@8bytes.org, iommu@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
Date: Tue, 21 Apr 2026 16:56:47 +0100	[thread overview]
Message-ID: <0fdf4b1f-90f2-4f69-9d2b-dc5f608e9c1c@arm.com> (raw)
In-Reply-To: <tencent_F6E384A40D990A279B460A0CDE1927FDF509@qq.com>

On 18/04/2026 6:31 am, leo.jiang1224@foxmail.com wrote:
> From: LoserJL <leo.jiang1224@foxmail.com>
> 
> In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> allocates at least PAGE_SIZE, retrying with a smaller size after
> a PAGE_SIZE failure is logically redundant.

Says who? It's certainly not a guarantee offered by the DMA API itself, 
and indeed some allocation paths can definitely still allocate less than 
a page - e.g. anything which hits a per-device or global coherent pool.

> Moreover, if a sub-page retry were to succeed due to concurrent memory
> release, the hardware would be configured with a smaller queue depth
> despite a full page being allocated. This leads to inefficient memory
> usage and unnecessary hardware performance limitation.
> 
> Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> consistency and optimal hardware configuration.

That's really not an argument - even if an allocator does happen to 
over-allocate for the requested size, that is hardly the caller's 
concern; and as far as "optimal" queue sizes go in this case, those very 
much depend on the number of CPUs issuing commands and volume of 
expected stall/PRI events - in many cases PAGE_SIZE would already be far 
too small to really work well.

Also note that if we _were_ to fail to allocate a PAGE_SIZE or smaller 
queue, there would be very little chance of the subsequent allocation(s) 
for the stream table succeeding, so realistically the driver is probably 
going to end up failing to probe in such circumstances anyway.

Thanks,
Robin.

> Signed-off-by: LoserJL <leo.jiang1224@foxmail.com>
> ---
>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f0..e0ec118ff560 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -4418,7 +4418,14 @@ int arm_smmu_init_one_queue(struct arm_smmu_device *smmu,
>   		qsz = ((1 << q->llq.max_n_shift) * dwords) << 3;
>   		q->base = dmam_alloc_coherent(smmu->dev, qsz, &q->base_dma,
>   					      GFP_KERNEL);
> -		if (q->base || qsz < PAGE_SIZE)
> +		/*
> +		 * If allocation succeeds, we're done. If it fails, only retry
> +		 * if the requested size is still larger than a page. Since
> +		 * dmam_alloc_coherent() allocates at least PAGE_SIZE, retrying
> +		 * with a sub-page size is logically redundant and could lead
> +		 * to sub-optimal hardware configuration.
> +		 */
> +		if (q->base || qsz <= PAGE_SIZE)
>   			break;
>   
>   		q->llq.max_n_shift--;



  parent reply	other threads:[~2026-04-21 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-18  5:31 [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE leo.jiang1224
2026-04-21 15:26 ` Will Deacon
2026-04-21 15:56 ` Robin Murphy [this message]
2026-04-21 16:38   ` Will Deacon
2026-04-22  9:13     ` Leo Jiang
2026-04-22  9:28       ` [PATCH v2] iommu/arm-smmu-v3: Limit queue allocation retry boundary to PAGE_SIZE Leo Jiang

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=0fdf4b1f-90f2-4f69-9d2b-dc5f608e9c1c@arm.com \
    --to=robin.murphy@arm.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=leo.jiang1224@foxmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=will@kernel.org \
    /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