From: Tomasz Nowicki <tnowicki@caviumnetworks.com>
To: Robin Murphy <robin.murphy@arm.com>, joro@8bytes.org
Cc: iommu@lists.linux-foundation.org, thunder.leizhen@huawei.com,
nwatters@codeaurora.org, tomasz.nowicki@caviumnetworks.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 5/6] iommu/iova: Extend rbtree node caching
Date: Wed, 20 Sep 2017 14:59:09 +0200 [thread overview]
Message-ID: <ee693561-67c4-ed2a-9462-e783dfc013c2@caviumnetworks.com> (raw)
In-Reply-To: <223f0fddac0dcefc43ad81594979875967745c58.1505829018.git.robin.murphy@arm.com>
Hi Robin,
On 19.09.2017 18:31, Robin Murphy wrote:
> The cached node mechanism provides a significant performance benefit for
> allocations using a 32-bit DMA mask, but in the case of non-PCI devices
> or where the 32-bit space is full, the loss of this benefit can be
> significant - on large systems there can be many thousands of entries in
> the tree, such that walking all the way down to find free space every
> time becomes increasingly awful.
>
> Maintain a similar cached node for the whole IOVA space as a superset of
> the 32-bit space so that performance can remain much more consistent.
>
> Inspired by work by Zhen Lei <thunder.leizhen@huawei.com>.
>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Zhen Lei <thunder.leizhen@huawei.com>
> Tested-by: Nate Watterson <nwatters@codeaurora.org>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>
> v4:
> - Adjust to simplified __get_cached_rbnode() behaviour
> - Cosmetic tweaks
>
> drivers/iommu/iova.c | 43 +++++++++++++++++++++----------------------
> include/linux/iova.h | 3 ++-
> 2 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index c93a6c46bcb1..a125a5786dbf 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -51,6 +51,7 @@ init_iova_domain(struct iova_domain *iovad, unsigned long granule,
>
> spin_lock_init(&iovad->iova_rbtree_lock);
> iovad->rbroot = RB_ROOT;
> + iovad->cached_node = NULL;
> iovad->cached32_node = NULL;
> iovad->granule = granule;
> iovad->start_pfn = start_pfn;
> @@ -119,39 +120,38 @@ __get_cached_rbnode(struct iova_domain *iovad, unsigned long limit_pfn)
> if (limit_pfn <= iovad->dma_32bit_pfn && iovad->cached32_node)
> return iovad->cached32_node;
>
> + if (iovad->cached_node)
> + return iovad->cached_node;
> +
> return &iovad->anchor.node;
> }
>
> static void
> -__cached_rbnode_insert_update(struct iova_domain *iovad,
> - unsigned long limit_pfn, struct iova *new)
> +__cached_rbnode_insert_update(struct iova_domain *iovad, struct iova *new)
> {
> - if (limit_pfn != iovad->dma_32bit_pfn)
> - return;
> - iovad->cached32_node = &new->node;
> + if (new->pfn_hi < iovad->dma_32bit_pfn)
> + iovad->cached32_node = &new->node;
> + else
> + iovad->cached_node = &new->node;
> }
>
> static void
> __cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free)
> {
> struct iova *cached_iova;
> - struct rb_node *curr;
> + struct rb_node **curr;
>
> - if (!iovad->cached32_node)
> + if (free->pfn_hi < iovad->dma_32bit_pfn)
> + curr = &iovad->cached32_node;
> + else
> + curr = &iovad->cached_node;
> +
> + if (!*curr)
> return;
> - curr = iovad->cached32_node;
> - cached_iova = rb_entry(curr, struct iova, node);
>
> - if (free->pfn_lo >= cached_iova->pfn_lo) {
> - struct rb_node *node = rb_next(&free->node);
> - struct iova *iova = rb_entry(node, struct iova, node);
> -
> - /* only cache if it's below 32bit pfn */
> - if (node && iova->pfn_lo < iovad->dma_32bit_pfn)
> - iovad->cached32_node = node;
> - else
> - iovad->cached32_node = NULL;
> - }
> + cached_iova = rb_entry(*curr, struct iova, node);
> + if (free->pfn_lo >= cached_iova->pfn_lo)
> + *curr = rb_next(&free->node);
IMO, we may incorrectly update iovad->cached32_node here.
32-bit boundary
-------- -------- | -------- --------
| | | | | | | | |
---- IOVA0 ----- IOVA1 ----------------- IOVA3 ----- anchor |
| | | | | | | | |
-------- -------- | -------- --------
If we free last IOVA from 32-bit space (IOVA1) we will update
iovad->cached32_node to IOVA3.
Thanks,
Tomasz
next prev parent reply other threads:[~2017-09-20 12:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-19 16:31 [PATCH v4 0/6] Optimise 64-bit IOVA allocations Robin Murphy
2017-09-19 16:31 ` [PATCH v4 1/6] iommu/iova: Optimise rbtree searching Robin Murphy
2017-09-19 16:31 ` [PATCH v4 2/6] iommu/iova: Optimise the padding calculation Robin Murphy
2017-09-19 16:31 ` [PATCH v4 3/6] iommu/iova: Add rbtree anchor node Robin Murphy
2017-09-19 16:31 ` [PATCH v4 4/6] iommu/iova: Simplify cached node logic Robin Murphy
2017-09-19 16:31 ` [PATCH v4 5/6] iommu/iova: Extend rbtree node caching Robin Murphy
2017-09-20 12:59 ` Tomasz Nowicki [this message]
2017-09-20 17:27 ` Robin Murphy
2017-09-19 16:31 ` [PATCH v4 6/6] iommu/iova: Make dma_32bit_pfn implicit Robin Murphy
2017-09-20 11:02 ` [PATCH v4 7/6] iommu/iova: Make cached_node always valid Robin Murphy
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=ee693561-67c4-ed2a-9462-e783dfc013c2@caviumnetworks.com \
--to=tnowicki@caviumnetworks.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nwatters@codeaurora.org \
--cc=robin.murphy@arm.com \
--cc=thunder.leizhen@huawei.com \
--cc=tomasz.nowicki@caviumnetworks.com \
/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
all inboxes | Powered by JetHome®