From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Niklas Schnelle <schnelle@linux.ibm.com>,
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: 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 v6 6/6] iommu/dma: Make flush queue sizes and timeout driver configurable
Date: Fri, 17 Feb 2023 09:41:12 -0500 [thread overview]
Message-ID: <bc234db3-f4c9-ff5a-6c19-699c50514fc5@linux.ibm.com> (raw)
In-Reply-To: <20230215120327.947336-7-schnelle@linux.ibm.com>
On 2/15/23 7:03 AM, Niklas Schnelle wrote:
> Flush queues currently use a fixed compile time size of 256 entries.
> This being a power of 2 allows the compiler to use shift and mask
> instead of more expensive modulo operations. With per-CPU flush queues
> larger queue sizes would hit per-CPU allocation limits, with a single
> flush queue these limits do not apply however. Also with single queues
> being particularly suitable for virtualized environments with expensive
> IOTLB flushes these benefit especially from larger queues and thus fewer
> flushes.
>
> To this end re-order struct iova_fq so we can use a dynamic array and
> introduce the flush queue size and timeouts as new options in the
> dma_iommu_options struct. So as not to lose the shift and mask
> optimization, check that the variable length is a power of 2 and use
> explicit shift and mask instead of letting the compiler optimize this.
>
> In the s390 IOMMU driver a large fixed queue size and timeout is then
> set together with single queue mode bringing its performance on s390
> paged memory guests on par with the previous s390 specific DMA API
> implementation.
>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> #s390
> +#define S390_IOMMU_SINGLE_FQ_SIZE 32768
> +#define S390_IOMMU_SINGLE_FQ_TIMEOUT 1000
> +
One question about these values however, was there a rationale to choosing these particular numbers (anything worth documenting?) or were they were simply chosen because they showed similar characteristics to the previous DMA approach? I'm mostly wondering if it's worth experimenting with other values here in the future to see what kind of impact it would have.
next prev parent reply other threads:[~2023-02-17 14:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-15 12:03 [PATCH v6 0/6] iommu/dma: s390 DMA API conversion and optimized IOTLB flushing Niklas Schnelle
2023-02-15 12:03 ` [PATCH v6 1/6] s390/ism: Set DMA coherent mask Niklas Schnelle
2023-02-15 12:03 ` [PATCH v6 2/6] iommu: Allow .iotlb_sync_map to fail and handle s390's -ENOMEM return Niklas Schnelle
2023-02-15 12:03 ` [PATCH v6 3/6] s390/pci: prepare is_passed_through() for dma-iommu Niklas Schnelle
2023-02-15 12:03 ` [PATCH v6 4/6] s390/pci: Use dma-iommu layer Niklas Schnelle
2023-02-15 18:00 ` Matthew Rosato
2023-02-17 8:51 ` Niklas Schnelle
2023-02-17 14:56 ` Matthew Rosato
2023-02-17 16:34 ` Niklas Schnelle
2023-02-15 12:03 ` [PATCH v6 5/6] iommu/dma: Allow a single FQ in addition to per-CPU FQs Niklas Schnelle
2023-02-17 14:40 ` Matthew Rosato
2023-02-15 12:03 ` [PATCH v6 6/6] iommu/dma: Make flush queue sizes and timeout driver configurable Niklas Schnelle
2023-02-17 14:41 ` Matthew Rosato [this message]
2023-02-17 15:40 ` Niklas Schnelle
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=bc234db3-f4c9-ff5a-6c19-699c50514fc5@linux.ibm.com \
--to=mjrosato@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=pmorel@linux.ibm.com \
--cc=robin.murphy@arm.com \
--cc=schnelle@linux.ibm.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