All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
To: joro@8bytes.org, iommu@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, robin.murphy@arm.com
Cc: tomasz.nowicki@cavium.com, jnair@caviumnetworks.com,
	Robert.Richter@cavium.com, Vadim.Lomovtsev@cavium.com,
	Jan.Glauber@cavium.com, gklkml16@gmail.com
Subject: [PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA
Date: Thu, 19 Apr 2018 22:42:34 +0530	[thread overview]
Message-ID: <20180419171234.11053-1-ganapatrao.kulkarni@cavium.com> (raw)

The performance drop is observed with long hours iperf testing using 40G
cards. This is mainly due to long iterations in finding the free iova
range in 32bit address space.

In current implementation for 64bit PCI devices, there is always first
attempt to allocate iova from 32bit(SAC preferred over DAC) address
range. Once we run out 32bit range, there is allocation from higher range,
however due to cached32_node optimization it does not suppose to be
painful. cached32_node always points to recently allocated 32-bit node.
When address range is full, it will be pointing to last allocated node
(leaf node), so walking rbtree to find the available range is not
expensive affair. However this optimization does not behave well when
one of the middle node is freed. In that case cached32_node is updated
to point to next iova range. The next iova allocation will consume free
range and again update cached32_node to itself. From now on, walking
over 32-bit range is more expensive.

This patch adds fix to update cached node to leaf node when there are no
iova free range left, which avoids unnecessary long iterations.

Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
---
 drivers/iommu/iova.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 83fe262..e6ee2ea 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -201,6 +201,12 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
 	} while (curr && new_pfn <= curr_iova->pfn_hi);
 
 	if (limit_pfn < size || new_pfn < iovad->start_pfn) {
+		/* No more cached node points to free hole, update to leaf node.
+		 */
+		struct iova *prev_iova;
+
+		prev_iova = rb_entry(prev, struct iova, node);
+		__cached_rbnode_insert_update(iovad, prev_iova);
 		spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
 		return -ENOMEM;
 	}
-- 
2.9.4

WARNING: multiple messages have this Message-ID (diff)
From: Ganapatrao Kulkarni <ganapatrao.kulkarni-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
To: joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	robin.murphy-5wv7dgnIgG8@public.gmane.org
Cc: Vadim.Lomovtsev-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
	Jan.Glauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
	gklkml16-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	tomasz.nowicki-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
	Robert.Richter-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
	jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org
Subject: [PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA
Date: Thu, 19 Apr 2018 22:42:34 +0530	[thread overview]
Message-ID: <20180419171234.11053-1-ganapatrao.kulkarni@cavium.com> (raw)

The performance drop is observed with long hours iperf testing using 40G
cards. This is mainly due to long iterations in finding the free iova
range in 32bit address space.

In current implementation for 64bit PCI devices, there is always first
attempt to allocate iova from 32bit(SAC preferred over DAC) address
range. Once we run out 32bit range, there is allocation from higher range,
however due to cached32_node optimization it does not suppose to be
painful. cached32_node always points to recently allocated 32-bit node.
When address range is full, it will be pointing to last allocated node
(leaf node), so walking rbtree to find the available range is not
expensive affair. However this optimization does not behave well when
one of the middle node is freed. In that case cached32_node is updated
to point to next iova range. The next iova allocation will consume free
range and again update cached32_node to itself. From now on, walking
over 32-bit range is more expensive.

This patch adds fix to update cached node to leaf node when there are no
iova free range left, which avoids unnecessary long iterations.

Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
---
 drivers/iommu/iova.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 83fe262..e6ee2ea 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -201,6 +201,12 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
 	} while (curr && new_pfn <= curr_iova->pfn_hi);
 
 	if (limit_pfn < size || new_pfn < iovad->start_pfn) {
+		/* No more cached node points to free hole, update to leaf node.
+		 */
+		struct iova *prev_iova;
+
+		prev_iova = rb_entry(prev, struct iova, node);
+		__cached_rbnode_insert_update(iovad, prev_iova);
 		spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
 		return -ENOMEM;
 	}
-- 
2.9.4

             reply	other threads:[~2018-04-19 17:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 17:12 Ganapatrao Kulkarni [this message]
2018-04-19 17:12 ` [PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA Ganapatrao Kulkarni
2018-04-23 16:37 ` Robin Murphy
2018-04-23 16:37   ` Robin Murphy
2018-04-23 17:41   ` Ganapatrao Kulkarni
2018-04-23 17:41     ` Ganapatrao Kulkarni
2018-04-26  9:45     ` Ganapatrao Kulkarni
2018-04-26  9:45       ` Ganapatrao Kulkarni
2018-05-21  1:15       ` Ganapatrao Kulkarni
2018-05-21  1:15         ` Ganapatrao Kulkarni
2018-06-04  4:06         ` Ganapatrao Kulkarni
2018-07-12  7:45           ` Ganapatrao Kulkarni
2018-07-25 14:20             ` Robin Murphy
2018-07-27 12:56               ` Ganapatrao Kulkarni
2018-07-27 16:18                 ` Robin Murphy
2018-07-30  7:10                   ` Ganapatrao Kulkarni
2018-07-31  2:40                     ` Ganapatrao Kulkarni
2018-07-31  2:40                       ` Ganapatrao Kulkarni

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=20180419171234.11053-1-ganapatrao.kulkarni@cavium.com \
    --to=ganapatrao.kulkarni@cavium.com \
    --cc=Jan.Glauber@cavium.com \
    --cc=Robert.Richter@cavium.com \
    --cc=Vadim.Lomovtsev@cavium.com \
    --cc=gklkml16@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jnair@caviumnetworks.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tomasz.nowicki@cavium.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 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.