public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Wenjia Zhang <wenjia@linux.ibm.com>
Cc: Matthew Rosato <mjrosato@linux.ibm.com>,
	Gerd Bayer <gbayer@linux.ibm.com>,
	Pierre Morel <pmorel@linux.ibm.com>,
	iommu@lists.linux.dev, linux-s390@vger.kernel.org,
	borntraeger@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
	gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
	svens@linux.ibm.com, linux-kernel@vger.kernel.org,
	Julian Ruess <julianr@linux.ibm.com>
Subject: Re: [PATCH v7 0/6] iommu/dma: s390 DMA API conversion and optimized IOTLB flushing
Date: Tue, 07 Mar 2023 14:16:37 +0100	[thread overview]
Message-ID: <a5e2178782c862dd3241ce821a471b584b8089a9.camel@linux.ibm.com> (raw)
In-Reply-To: <20230220152222.1818344-1-schnelle@linux.ibm.com>

On Mon, 2023-02-20 at 16:22 +0100, Niklas Schnelle wrote:
> Hi All,
> 
> This patch series converts s390's PCI support from its platform specific DMA
> API implementation in arch/s390/pci/pci_dma.c to the common DMA IOMMU layer.
> The conversion itself is done in patches 3-4 with patch 2 providing the final
> necessary IOMMU driver improvement to handle s390's special IOTLB flush
> out-of-resource indication in virtualized environments. Patches 1-2 may be
> applied independently. The conversion itself only touches the s390 IOMMU driver
> and s390 arch code moving over remaining functions from the s390 DMA API
> implementation. No changes to common code are necessary.
> 
> After patch 4 the basic conversion is done and on our partitioning machine
> hypervisor LPAR performance matches or exceeds the existing code. When running
> under z/VM or KVM however, performance plummets to about half of the existing
> code due to a much higher rate of IOTLB flushes for unmapped pages. Due to the
> hypervisors use of IOTLB flushes to synchronize their shadow tables these are
> very expensive and minimizing them is key for regaining the performance loss.
> 
> To this end patches 5-6 propose a new, single queue, IOTLB flushing scheme as
> an alternative to the existing per-CPU flush queues. Introducing an alternative
> scheme was also suggested by Robin Murphy[1]. In the previous RFC of this
> conversion Robin suggested reusing more of the existing queuing logic which
> I incorporated since v2. The single queue mode is introduced in patch
> 5 together with a new dma_iommu_options struct and tune_dma_iommu callback in
> IOMMU ops which allows IOMMU drivers to switch to a single flush queue.
> 
> Then patch 6 enables variable queue sizes using power of 2 queue sizes and
> shift/mask to keep performance as close to the existing code as possible. The
> variable queue size and a variable timeout are added to the dma_iommu_options
> struct and utilized by s390 in the z/VM and KVM guest cases. As it is
> implemented in common code the single queue IOTLB flushing scheme can of course
> be used by other platforms with expensive IOTLB flushes. Particularly
> virtio-iommu may be a candidate.
> 
> In a previous version I verified that the new scheme does work on my x86_64
> Ryzen workstation by locally modifying iommu_subsys_init() to default to the
> single queue mode and verifying its use via "/sys/.../iommu_group/type". I did
> not find problems with an AMD GPU, Intel NIC (with SR-IOV and KVM
> pass-through), NVMes or any on board peripherals.
> 
> As with previous series this is available via my git.kernel.org tree[3] in the
> dma_iommu_v7 branch with signed s390_dma_iommu_v7 tag. This version applies
> on top of iommu-next to incorporate the ops->set_platform_dma() and GFP
> changes.

FYI this patch set now applies cleanly (and works) on v6.3-rc1. If need
be I can resend with Matt's R-b added but other than that I currently
don't have open TODOs for this so review away.

Thanks,
Niklas


      parent reply	other threads:[~2023-03-07 13:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-20 15:22 [PATCH v7 0/6] iommu/dma: s390 DMA API conversion and optimized IOTLB flushing Niklas Schnelle
2023-02-20 15:22 ` [PATCH v7 1/6] s390/ism: Set DMA coherent mask Niklas Schnelle
2023-02-20 15:22 ` [PATCH v7 2/6] iommu: Allow .iotlb_sync_map to fail and handle s390's -ENOMEM return Niklas Schnelle
2023-02-20 15:22 ` [PATCH v7 3/6] s390/pci: prepare is_passed_through() for dma-iommu Niklas Schnelle
2023-02-20 15:22 ` [PATCH v7 4/6] s390/pci: Use dma-iommu layer Niklas Schnelle
2023-02-21 21:05   ` Matthew Rosato
2023-02-20 15:22 ` [PATCH v7 5/6] iommu/dma: Allow a single FQ in addition to per-CPU FQs Niklas Schnelle
2023-02-20 15:22 ` [PATCH v7 6/6] iommu/dma: Make flush queue sizes and timeout driver configurable Niklas Schnelle
2023-03-07 13:16 ` Niklas Schnelle [this message]

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=a5e2178782c862dd3241ce821a471b584b8089a9.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gbayer@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=julianr@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=robin.murphy@arm.com \
    --cc=svens@linux.ibm.com \
    --cc=wenjia@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox