This bug was fixed in the package linux-aws - 6.2.0-1002.2
---------------
linux-aws (6.2.0-1002.2) lunar; urgency=medium
* lunar/linux-aws: 6.2.0-1002.2 -proposed tracker (LP: #2011518)
-- Paolo Pisati <paolo.pis...@canonical.com> Tue, 14 Mar 2023 11:04:29
+0100
** Changed in: linux-aws (Ubuntu Lunar)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-aws in Ubuntu.
https://bugs.launchpad.net/bugs/1806488
Title:
Support non-strict iommu mode on arm64
Status in linux package in Ubuntu:
Fix Released
Status in linux-aws package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux-aws source package in Bionic:
Invalid
Status in linux source package in Cosmic:
Fix Released
Status in linux-aws source package in Cosmic:
Invalid
Status in linux source package in Disco:
Fix Released
Status in linux-aws source package in Disco:
Invalid
Status in linux source package in Jammy:
Invalid
Status in linux-aws source package in Jammy:
Fix Released
Status in linux source package in Kinetic:
Invalid
Status in linux-aws source package in Kinetic:
Fix Released
Status in linux source package in Lunar:
Fix Released
Status in linux-aws source package in Lunar:
Fix Released
Bug description:
[Impact]
The Intel IOMMU driver provides an option for strict mode. When disabled,
batching of IOTLB flush operations is permitted, allowing the user to trade-off
isolation for improved performance. Ubuntu's kernel currently lacks a parity
for this feature for ARM.
There's a significant performance gain to be had by removing the need
to flush the IOMMU TLB on every unmap on arm64. I'm seeing a 25%
performance gain w/ fio reads on a single NVMe device.
This mode of operation is available for x86 via the
"intel_iommu=strict" parameter. Upstream now exposes an equivalent
feature for ARM platforms via the "iommu.strict=[0|1]" parameter,
while retaining the default strict-enabled mode.
[Test Case]
Run fio with the following config before and after applying the patches and
collection IOPS count. Run again after applying the patches. Finally, run a 3rd
time after adding iommu.strict=0 to the kernel commandline.
Performance should not regress after the update. Performance should
further improve after adding iommu.strict=0 - but if it doesn't for
some reason, that is not a regression.
$ cat fio.rc
[global]
rw=read
direct=1
ioengine=libaio
iodepth=2048
numjobs=10
bs=4k
group_reporting=1
group_reporting=1
cpumask=0xff
runtime=100
loops = 10000
[job1]
filename=/dev/nvme0n1
[Fix]
44f6876a00e83 iommu/arm-smmu: Support non-strict mode
b2dfeba654cb0 iommu/io-pgtable-arm-v7s: Add support for non-strict mode
9662b99a19abc iommu/arm-smmu-v3: Add support for non-strict mode
b6b65ca20bc93 iommu/io-pgtable-arm: Add support for non-strict mode
68a6efe86f6a1 iommu: Add "iommu.strict" command line option
2da274cdf998a iommu/dma: Add support for non-strict mode
07fdef34d2be6 iommu/arm-smmu-v3: Implement flush_iotlb_all hook
85c7a0f1ef624 iommu/io-pgtable-arm: Fix race handling in split_blk_unmap()
[Regression Risk]
Most of these patches are specific to ARM, and have been regression tested on
both arm64 (HiSilicon D06) and armhf (QEMU virt) using "stress-ng --vm $(nproc)"
2 patches do touch arch-indep code however:
> 68a6efe86f6a1 iommu: Add "iommu.strict" command line option
Adds a new command line option and sets an attribute that iommu drivers can
optionally react to. Doesn't change default behavior.
> 2da274cdf998a iommu/dma: Add support for non-strict mode
This driver is only built for arm64 and ppc64el (determined by looking at the
build logs). Most of this patch only changes behavior in the non-default (and
new) iommu.strict=0 case. The exception, which is called out in the commit
message, is this hunk:
- WARN_ON(iommu_unmap(domain, dma_addr, size) != size);
+ WARN_ON(iommu_unmap_fast(domain, dma_addr, size) != size);
+ if (!cookie->fq_domain)
+ iommu_tlb_sync(domain);
In the default case, where fq_domain will be NULl, we are now factoring
iommu_unmap() into:
iommu_unmap_fast()
iommu_tlb_sync()
Looking at the source to iommu_unmap() confirms that this is
functionally equivalent.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1806488/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
