From: John Garry <john.garry@huawei.com>
To: <joro@8bytes.org>, <will@kernel.org>, <robin.murphy@arm.com>,
<hch@lst.de>, <m.szyprowski@samsung.com>
Cc: <iommu@lists.linux-foundation.org>, <baolu.lu@linux.intel.com>,
<linux-kernel@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
<linuxarm@huawei.com>, <sai.praneeth.prakhya@intel.com>,
John Garry <john.garry@huawei.com>
Subject: [PATCH v2 00/15] dma mapping/iommu: Allow IOMMU IOVA rcache range to be configured
Date: Mon, 10 May 2021 22:17:14 +0800 [thread overview]
Message-ID: <1620656249-68890-1-git-send-email-john.garry@huawei.com> (raw)
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This is much more pronounced from commit 4e89dce72521 ("iommu/iova: Retry
from last rb tree node if iova search fails"), as discussed at [0].
IOVAs which cannot be cached are highly involved in the IOVA aging issue,
as discussed at [1].
This series allows the IOVA rcache range be configured, so that we may
cache all IOVAs per domain, thus improving performance.
A new IOMMU group sysfs file is added - max_opt_dma_size - which is used
indirectly to configure the IOVA rcache range:
/sys/kernel/iommu_groups/X/max_opt_dma_size
This file is updated same as how the IOMMU group default domain type is
updated, i.e. must unbind the only device in the group first. However, the
IOMMU default domain is reallocated in the device driver reprobe, and not
immediately.
In addition, we keep (from v1 series) the DMA mapping API to allow DMA max
optimised size be set from a LLDD. How it works is a lot different. When
the LLDD calls this during probe, once the value is successfully recorded, we
return -EDEFER_PROBE. In the reprobe, the IOMM group default domain is
reallocated, and the new IOVA domain rcache upper limit is set according
to that DMA max optimised size. As such, we don't operate on a live IOMMU
domain.
Note that the DMA mapping API frontend is not strictly required, but saves
the LLDD calling IOMMU APIs directly, that being not preferred.
Some figures for storage scenario:
v5.13-rc1 baseline: 1200K IOPS
With series: 1800K IOPS
All above are for IOMMU strict mode. Non-strict mode gives ~1800K IOPS in
all scenarios.
Patch breakdown:
1-11: Add support for setting DMA max optimised size via sysfs
12-15: Add support for setting DMA max optimised size from LLDD
[0] https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leizhen@huawei.com/
[1] https://lore.kernel.org/linux-iommu/1607538189-237944-1-git-send-email-john.garry@huawei.com/
Differences to v1:
- Many
- Change method to not operate on a 'live' IOMMU domain:
- rather, force device driver to be re-probed once
dma_max_opt_size is set, and reconfig a new IOMMU group then
- Add iommu sysfs max_dma_opt_size file, and allow updating same as how
group type is changed
John Garry (15):
iommu: Reactor iommu_group_store_type()
iova: Allow rcache range upper limit to be flexible
iommu: Allow max opt DMA len be set for a group via sysfs
iommu: Add iommu_group_get_max_opt_dma_size()
iova: Add iova_domain_len_is_cached()
iommu: Allow iommu_change_dev_def_domain() realloc default domain for
same type
iommu: Add iommu_realloc_dev_group()
dma-iommu: Add iommu_reconfig_dev_group_dma()
iova: Add init_iova_domain_ext()
dma-iommu: Use init_iova_domain_ext() for IOVA domain init
dma-iommu: Reconfig group domain
iommu: Add iommu_set_dev_dma_opt_size()
dma-mapping: Add dma_set_max_opt_size()
dma-iommu: Add iommu_dma_set_opt_size()
scsi: hisi_sas: Set max optimal DMA size for v3 hw
drivers/iommu/dma-iommu.c | 51 +++++-
drivers/iommu/iommu.c | 231 +++++++++++++++++++------
drivers/iommu/iova.c | 61 +++++--
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 5 +
include/linux/dma-iommu.h | 4 +
include/linux/dma-map-ops.h | 1 +
include/linux/dma-mapping.h | 8 +
include/linux/iommu.h | 19 ++
include/linux/iova.h | 21 ++-
kernel/dma/mapping.c | 11 ++
10 files changed, 344 insertions(+), 68 deletions(-)
--
2.26.2
next reply other threads:[~2021-05-10 14:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 14:17 John Garry [this message]
2021-05-10 14:17 ` [PATCH v2 01/15] iommu: Reactor iommu_group_store_type() John Garry
2021-05-10 14:17 ` [PATCH v2 02/15] iova: Allow rcache range upper limit to be flexible John Garry
2021-05-10 14:17 ` [PATCH v2 03/15] iommu: Allow max opt DMA len be set for a group via sysfs John Garry
2021-05-10 14:17 ` [PATCH v2 04/15] iommu: Add iommu_group_get_max_opt_dma_size() John Garry
2021-05-10 14:17 ` [PATCH v2 05/15] iova: Add iova_domain_len_is_cached() John Garry
2021-05-10 14:17 ` [PATCH v2 06/15] iommu: Allow iommu_change_dev_def_domain() realloc default domain for same type John Garry
2021-05-10 14:17 ` [PATCH v2 07/15] iommu: Add iommu_realloc_dev_group() John Garry
2021-05-10 14:17 ` [PATCH v2 08/15] dma-iommu: Add iommu_reconfig_dev_group_dma() John Garry
2021-05-10 14:17 ` [PATCH v2 09/15] iova: Add init_iova_domain_ext() John Garry
2021-05-10 17:50 ` kernel test robot
2021-05-10 17:50 ` [RFC PATCH] iova: __init_iova_domain can be static kernel test robot
2021-05-10 14:17 ` [PATCH v2 10/15] dma-iommu: Use init_iova_domain_ext() for IOVA domain init John Garry
2021-05-10 14:17 ` [PATCH v2 11/15] dma-iommu: Reconfig group domain John Garry
2021-05-10 14:17 ` [PATCH v2 12/15] iommu: Add iommu_set_dev_dma_opt_size() John Garry
2021-05-10 14:17 ` [PATCH v2 13/15] dma-mapping: Add dma_set_max_opt_size() John Garry
2021-05-10 14:17 ` [PATCH v2 14/15] dma-iommu: Add iommu_dma_set_opt_size() John Garry
2021-05-10 14:17 ` [PATCH v2 15/15] scsi: hisi_sas: Set max optimal DMA size for v3 hw John Garry
2021-05-20 8:28 ` [PATCH v2 00/15] dma mapping/iommu: Allow IOMMU IOVA rcache range to be configured John Garry
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=1620656249-68890-1-git-send-email-john.garry@huawei.com \
--to=john.garry@huawei.com \
--cc=baolu.lu@linux.intel.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=sai.praneeth.prakhya@intel.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