From: Nate Watterson <nwatters-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: will.deacon-5wv7dgnIgG8@public.gmane.org,
damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
sunil.kovvuri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 0/3] IOVA allocation improvements for iommu-dma
Date: Wed, 22 Mar 2017 13:43:16 -0400 [thread overview]
Message-ID: <b665e8511ef524fce0c7cc00b7920cba@codeaurora.org> (raw)
In-Reply-To: <cover.1489581865.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
On 2017-03-15 09:33, Robin Murphy wrote:
> Hi all,
Hi Robin,
>
> Here's the first bit of lock contention removal to chew on - feedback
> welcome! Note that for the current users of the io-pgtable framework,
> this is most likely to simply push more contention onto the io-pgtable
> lock, so may not show a great improvement alone. Will and I both have
> rough proof-of-concept implementations of lock-free io-pgtable code
> which we need to sit down and agree on at some point, hopefullt fairly
> soon.
>
> I've taken the opportunity to do a bit of cleanup and refactoring
> within the series to make the final state of the code nicer, but the
> diffstat still turns out surprisingly reasonable in the end - it would
> actually be negative but for the new comments!
>
> Magnus, Shimoda-san, the first two patches should be of interest as
> they
> constitute the allocation rework I mentioned a while back[1] - if you
> still need to implement that scary workaround, this should make it
> simple to hook IPMMU-specific calls into the alloc and free paths, and
> let the driver take care of the details internally.
I've tested your patches on a QDF2400 platform and generally
see modest improvements in iperf/fio performance. As you
suspected would happen, contention has indeed moved to the
io-pgtable lock. I am looking forward to testing with the
lock-free io-pgtable implementation, however I suspect that
there will still be contention issues acquiring the (SMMUv3)
cmdq lock on the unmap path.
Reviewed/Tested-by: Nate Watterson <nwatters-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>
> Robin.
>
> [1]:https://lists.linuxfoundation.org/pipermail/iommu/2017-January/020189.html
>
> Robin Murphy (3):
> iommu/dma: Convert to address-based allocation
> iommu/dma: Clean up MSI IOVA allocation
> iommu/dma: Plumb in the per-CPU IOVA caches
>
> drivers/iommu/dma-iommu.c | 176
> ++++++++++++++++++++++++----------------------
> 1 file changed, 90 insertions(+), 86 deletions(-)
--
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux
Foundation Collaborative Project.
WARNING: multiple messages have this Message-ID (diff)
From: nwatters@codeaurora.org (Nate Watterson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] IOVA allocation improvements for iommu-dma
Date: Wed, 22 Mar 2017 13:43:16 -0400 [thread overview]
Message-ID: <b665e8511ef524fce0c7cc00b7920cba@codeaurora.org> (raw)
In-Reply-To: <cover.1489581865.git.robin.murphy@arm.com>
On 2017-03-15 09:33, Robin Murphy wrote:
> Hi all,
Hi Robin,
>
> Here's the first bit of lock contention removal to chew on - feedback
> welcome! Note that for the current users of the io-pgtable framework,
> this is most likely to simply push more contention onto the io-pgtable
> lock, so may not show a great improvement alone. Will and I both have
> rough proof-of-concept implementations of lock-free io-pgtable code
> which we need to sit down and agree on at some point, hopefullt fairly
> soon.
>
> I've taken the opportunity to do a bit of cleanup and refactoring
> within the series to make the final state of the code nicer, but the
> diffstat still turns out surprisingly reasonable in the end - it would
> actually be negative but for the new comments!
>
> Magnus, Shimoda-san, the first two patches should be of interest as
> they
> constitute the allocation rework I mentioned a while back[1] - if you
> still need to implement that scary workaround, this should make it
> simple to hook IPMMU-specific calls into the alloc and free paths, and
> let the driver take care of the details internally.
I've tested your patches on a QDF2400 platform and generally
see modest improvements in iperf/fio performance. As you
suspected would happen, contention has indeed moved to the
io-pgtable lock. I am looking forward to testing with the
lock-free io-pgtable implementation, however I suspect that
there will still be contention issues acquiring the (SMMUv3)
cmdq lock on the unmap path.
Reviewed/Tested-by: Nate Watterson <nwatters@codeaurora.org>
>
> Robin.
>
> [1]:https://lists.linuxfoundation.org/pipermail/iommu/2017-January/020189.html
>
> Robin Murphy (3):
> iommu/dma: Convert to address-based allocation
> iommu/dma: Clean up MSI IOVA allocation
> iommu/dma: Plumb in the per-CPU IOVA caches
>
> drivers/iommu/dma-iommu.c | 176
> ++++++++++++++++++++++++----------------------
> 1 file changed, 90 insertions(+), 86 deletions(-)
--
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux
Foundation Collaborative Project.
next prev parent reply other threads:[~2017-03-22 17:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 13:33 [PATCH 0/3] IOVA allocation improvements for iommu-dma Robin Murphy
2017-03-15 13:33 ` Robin Murphy
[not found] ` <cover.1489581865.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2017-03-15 13:33 ` [PATCH 1/3] iommu/dma: Convert to address-based allocation Robin Murphy
2017-03-15 13:33 ` Robin Murphy
2017-03-15 13:33 ` [PATCH 2/3] iommu/dma: Clean up MSI IOVA allocation Robin Murphy
2017-03-15 13:33 ` Robin Murphy
2017-03-15 13:33 ` [PATCH 3/3] iommu/dma: Plumb in the per-CPU IOVA caches Robin Murphy
2017-03-15 13:33 ` Robin Murphy
2017-03-22 17:43 ` Nate Watterson [this message]
2017-03-22 17:43 ` [PATCH 0/3] IOVA allocation improvements for iommu-dma Nate Watterson
2017-03-31 12:40 ` Will Deacon
2017-03-31 12:40 ` Will Deacon
[not found] ` <20170331124051.GI8967-5wv7dgnIgG8@public.gmane.org>
2017-03-31 13:13 ` Robin Murphy
2017-03-31 13:13 ` Robin Murphy
[not found] ` <10f9621a-41ca-bb3d-0e49-a2827022f608-5wv7dgnIgG8@public.gmane.org>
2017-03-31 14:33 ` Joerg Roedel
2017-03-31 14:33 ` Joerg Roedel
2017-03-16 13:18 ` Sunil Kovvuri
2017-03-16 13:18 ` Sunil Kovvuri
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=b665e8511ef524fce0c7cc00b7920cba@codeaurora.org \
--to=nwatters-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
--cc=damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
--cc=sunil.kovvuri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.