public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH] iommu: Default to lazy DMA mode on ARM64
@ 2026-04-02 19:59 Nafees Ahmed Abdul
  2026-04-03  2:28 ` Pranjal Shrivastava
  0 siblings, 1 reply; 3+ messages in thread
From: Nafees Ahmed Abdul @ 2026-04-02 19:59 UTC (permalink / raw)
  To: joro, will; +Cc: robin.murphy, iommu, linux-kernel, Nafees Ahmed Abdul

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.

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
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [RFC PATCH] iommu: Default to lazy DMA mode on ARM64
  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
  2026-04-06 22:43   ` Jason Gunthorpe
  0 siblings, 1 reply; 3+ messages in thread
From: Pranjal Shrivastava @ 2026-04-03  2:28 UTC (permalink / raw)
  To: Nafees Ahmed Abdul; +Cc: joro, will, robin.murphy, iommu, linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC PATCH] iommu: Default to lazy DMA mode on ARM64
  2026-04-03  2:28 ` Pranjal Shrivastava
@ 2026-04-06 22:43   ` Jason Gunthorpe
  0 siblings, 0 replies; 3+ messages in thread
From: Jason Gunthorpe @ 2026-04-06 22:43 UTC (permalink / raw)
  To: Pranjal Shrivastava
  Cc: Nafees Ahmed Abdul, joro, will, robin.murphy, iommu, linux-kernel

On Fri, Apr 03, 2026 at 02:28:17AM +0000, Pranjal Shrivastava wrote:

> 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.

Personally I really dislike these rando arch specific things.

What justification is there for any arch to be unique here?

I'd expect a single kconfig 'try to be strict by default' and that's
it. No arch override.

Jason

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-04-06 22:43 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2026-04-06 22:43   ` Jason Gunthorpe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox