AMD is trading DMA containment for lower latency on its APUs, and it is on by default

AMD's integrated graphics will give up the IOMMU's containment of direct memory access by default in the next Linux kernel, and AMD wrote the trade down in its own commit message. "Arming PerfOpt trades IOMMU DMA containment for lower DMA latency," the amdgpu patch says. "This is enabled by default for GPUs in the identity domain as a deliberate, documented policy and can be disabled with iommu_perfopt=0."

Processor dies on a silicon wafer. PerfOpt only applies to AMD's integrated graphics, and a discrete Radeon card does not take this path. Image: AMD

The work arrives in two commits by Mario Limonciello of AMD, authored on September 8 at 04:12 UTC and committed on September 25 by Joerg Roedel, the kernel's IOMMU maintainer, with an Acked-by from AMD's Alex Deucher. They are 6e87850d1a8f, "iommu/amd: Add PerfOpt IOMMU performance optimization support", and e74db71a3530, which enables it in amdgpu. Both were read at 21:40 UTC on October 10 through a GitHub mirror of the kernel.org linux-next tree, because git.kernel.org answers a bot check from here; the hashes and the text are the upstream ones.

What PerfOpt switches off, in AMD's words

PerfOpt is a hardware control defined in AMD's own IOMMU specification, at section 3.4.9. "This feature allows privileged integrated I/O devices (GPUs) to bypass the IOMMU when directly accessing system memory," the IOMMU commit says. "The IOMMU only enforces the IR/IW permission bits without GPA->SPA translations."

The module parameter's own documentation is blunter still. Arming it "disables ATS, PRI, PASID and SVA for the GPU and removes IOMMU DMA containment for it, trading isolation for lower DMA latency". AMD's argument for doing it anyway is scope: this only fires for a GPU that sits in the identity domain, which means it is doing direct DMA with the IOMMU checking read and write permission bits and nothing else, and the commit says that is safe there because "DTE[I]=0 means the IOMMU already returns target abort for ATS requests from this peripheral and the GPU manages its own TLB".

It is also limited to integrated parts. The code checks explicitly for AMD_IS_APU, because "the AMD IOMMU spec indicates this is only supported on integrated GPUs". A discrete Radeon card does not take this path.

Queued for the next kernel, not shipped

Both commits sit in linux-next, the integration tree, whose Makefile read 7.3.0-rc6 when it was checked at 21:40 UTC on October 10. That puts them in the Linux 7.4 merge window at the earliest, so no released kernel carries this and no distribution ships it yet.

The plumbing underneath is more careful than the default suggests. The enable bit is one control per IOMMU shared by every device behind it, so the driver reference counts it, "armed on the first requesting device and cleared on the last", and a suspend and resume cycle clears the bit and re-asserts it from that count. Failing to arm it is deliberately not fatal: "probe and resume warn and continue rather than aborting". The commits credit Jatin Kataria of Netflix as co-developer, with Tested-by trailers from Derek J. Clark and Boqun Feng.

No number appears anywhere in either commit. The only published measurements are Phoronix's own benchmarks, which reported on October 9 that on current-generation Ryzen AI APUs "the AI performance improved as much as 18~23%", and ran the same feature on an older ThinkPad P14s Gen 4 with a Ryzen 7 PRO 7840U and Radeon 780M graphics. Those are AI workload figures rather than frame rates.

Linux kernel graphics work for AMD hardware usually reaches readers as a fault rather than a policy, as it did when Valve said grey Linux VR streaming may be an AMD encoder bug. This one is a decision rather than a defect, and anyone who would rather keep the containment has a single switch for it: iommu_perfopt=0.