On Thu, Aug 15, 2019 at 12:19:58PM +0100, John Garry wrote: > On 14/08/2019 18:56, Will Deacon wrote: > > If you'd like to play with the patches, then I've also pushed them here: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=iommu/unmap > > > > but they should behave as a no-op on their own. > > As anticipated, my storage testing scenarios roughly give parity throughput > and CPU loading before and after this series. > > Patches to convert the > > Arm SMMUv3 driver to the new API are here: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=iommu/cmdq > > I quickly tested this again and now I see a performance lift: > > before (5.3-rc1) after > D05 8x SAS disks 907K IOPS 970K IOPS > D05 1x NVMe 450K IOPS 466K IOPS > D06 1x NVMe 467K IOPS 466K IOPS > > The CPU loading seems to track throughput, so nothing much to say there. > > Note: From 5.2 testing, I was seeing >900K IOPS from that NVMe disk for > !IOMMU.
Cheers, John. For interest, how do things look if you pass iommu.strict=0? That might give some indication about how much the invalidation is still hurting us. > BTW, what were your thoughts on changing > arm_smmu_atc_inv_domain()->arm_smmu_atc_inv_master() to batching? It seems > suitable, but looks untouched. Were you waiting for a resolution to the > performance issue which Leizhen reported? In principle, I'm supportive of such a change, but I'm not currently able to test any ATS stuff so somebody else would need to write the patch. Jean-Philippe is on holiday at the moment, but I'd be happy to review something from you if you send it out. Will _______________________________________________ iommu mailing list email@example.com https://lists.linuxfoundation.org/mailman/listinfo/iommu