All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pranjal Shrivastava <praan@google.com>
To: Nafees Ahmed Abdul <nafeabd@amazon.com>
Cc: joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] iommu: Default to lazy DMA mode on ARM64
Date: Fri, 3 Apr 2026 02:28:17 +0000	[thread overview]
Message-ID: <ac8lwTT0oQNT-JaL@google.com> (raw)
In-Reply-To: <20260402195913.32084-1-nafeabd@amazon.com>

Hi Nafees,

On Thu, Apr 02, 2026 at 07:59:13PM +0000, Nafees Ahmed Abdul wrote:
> ARM64 currently falls through to IOMMU_DEFAULT_DMA_STRICT, while
> X86 defaults to IOMMU_DEFAULT_DMA_LAZY. On ARM64 bare-metal
> systems with the ARM SMMU, strict mode causes synchronous TLBI
> + CMD_SYNC on every DMA unmap, resulting in significant
> throughput degradation for network-intensive workloads.
> 
> Benchmarked on an ARM64 bare-metal system (AWS m8g.metal-24xl)
> running Debian 13 with kernel 6.12.74, using iperf3:
> 
>   STRICT (default): 14.9 Gbps
>   LAZY:             39.8 Gbps
> 
> This is a 2.67x throughput improvement simply by switching the
> IOMMU default domain mode.
> 
> Distributions that do not explicitly override this Kconfig
> choice (e.g., Debian, SLES) silently get STRICT on ARM64,
> causing this regression on bare-metal systems. Changing the
> upstream default avoids the need for each distribution to
> independently carry this override.
> 

Thanks for the patch and the benchmarks.

However, I'm not sure why should we change the compile-time default for
all ARM64 systems? Currently, users can already achieve this behavior by
using the `iommu.strict=0` boot parameter.

Since IOMMU_DEFAULT_DMA_STRICT provides a higher security guarantee 
(preventing sub-page aliasing and potential "use-after-unmap" attacks),
keeping it as the default and allowing users to opt-in via the kernel cmd
line seems like the safer path, in my opinion. 

Additionally, distributions like Debian can also set this via their 
GRUB configurations for performance.

> Add ARM64 to the LAZY default to align with X86 behavior.
> 
> Signed-off-by: Nafees Ahmed Abdul <nafeabd@amazon.com>
> ---
>  drivers/iommu/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index f86262b11..2822aba75 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -96,7 +96,7 @@ config IOMMU_DEBUGFS
>  choice
>  	prompt "IOMMU default domain type"
>  	depends on IOMMU_API
> -	default IOMMU_DEFAULT_DMA_LAZY if X86 || S390
> +	default IOMMU_DEFAULT_DMA_LAZY if X86 || S390 || ARM64
>  	default IOMMU_DEFAULT_DMA_STRICT
>  	help
>  	  Choose the type of IOMMU domain used to manage DMA API usage by
 
Thanks,
Praan

  reply	other threads:[~2026-04-03  2:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02 19:59 [RFC PATCH] iommu: Default to lazy DMA mode on ARM64 Nafees Ahmed Abdul
2026-04-03  2:28 ` Pranjal Shrivastava [this message]
2026-04-06 22:43   ` Jason Gunthorpe
2026-04-07 11:25 ` Robin Murphy

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=ac8lwTT0oQNT-JaL@google.com \
    --to=praan@google.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nafeabd@amazon.com \
    --cc=robin.murphy@arm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.