Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1741406 > unrolled thread

[PATCH v2] iommu/iova: Try harder to allocate from rcache magazine

Started byRobin Murphy <robin.murphy@arm.com>
First post2017-09-28 12:40 +0200
Last post2017-09-28 15:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH v2] iommu/iova: Try harder to allocate from rcache magazine Robin Murphy <robin.murphy@arm.com> - 2017-09-28 12:40 +0200
    Re: [PATCH v2] iommu/iova: Try harder to allocate from rcache  magazine Joerg Roedel <joro@8bytes.org> - 2017-09-28 15:50 +0200

#1741406 — [PATCH v2] iommu/iova: Try harder to allocate from rcache magazine

FromRobin Murphy <robin.murphy@arm.com>
Date2017-09-28 12:40 +0200
Subject[PATCH v2] iommu/iova: Try harder to allocate from rcache magazine
Message-ID<uuEoy-7PA-21@gated-at.bofh.it>
When devices with different DMA masks are using the same domain, or for
PCI devices where we usually try a speculative 32-bit allocation first,
there is a fair possibility that the top PFN of the rcache stack at any
given time may be unsuitable for the lower limit, prompting a fallback
to allocating anew from the rbtree. Consequently, we may end up
artifically increasing pressure on the 32-bit IOVA space as unused IOVAs
accumulate lower down in the rcache stacks, while callers with 32-bit
masks also impose unnecessary rbtree overhead.

In such cases, let's try a bit harder to satisfy the allocation locally
first - scanning the whole stack should still be relatively inexpensive.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---

v2: There's no need for a 'proper' stack rotation

 drivers/iommu/iova.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 506780084425..bb392fdc7a1b 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -822,12 +822,21 @@ static bool iova_magazine_empty(struct iova_magazine *mag)
 static unsigned long iova_magazine_pop(struct iova_magazine *mag,
 				       unsigned long limit_pfn)
 {
+	int i;
+	unsigned long pfn;
+
 	BUG_ON(iova_magazine_empty(mag));
 
-	if (mag->pfns[mag->size - 1] > limit_pfn)
-		return 0;
+	/* Only fall back to the rbtree if we have no suitable pfns at all */
+	for (i = mag->size - 1; mag->pfns[i] > limit_pfn; i--)
+		if (i == 0)
+			return 0;
 
-	return mag->pfns[--mag->size];
+	/* Swap it to pop it */
+	pfn = mag->pfns[i];
+	mag->pfns[i] = mag->pfns[--mag->size];
+
+	return pfn;
 }
 
 static void iova_magazine_push(struct iova_magazine *mag, unsigned long pfn)
-- 
2.13.4.dirty

[toc] | [next] | [standalone]


#1741567 — Re: [PATCH v2] iommu/iova: Try harder to allocate from rcache magazine

FromJoerg Roedel <joro@8bytes.org>
Date2017-09-28 15:50 +0200
SubjectRe: [PATCH v2] iommu/iova: Try harder to allocate from rcache magazine
Message-ID<uuHmp-1aC-5@gated-at.bofh.it>
In reply to#1741406
On Thu, Sep 28, 2017 at 11:31:23AM +0100, Robin Murphy wrote:
> When devices with different DMA masks are using the same domain, or for
> PCI devices where we usually try a speculative 32-bit allocation first,
> there is a fair possibility that the top PFN of the rcache stack at any
> given time may be unsuitable for the lower limit, prompting a fallback
> to allocating anew from the rbtree. Consequently, we may end up
> artifically increasing pressure on the 32-bit IOVA space as unused IOVAs
> accumulate lower down in the rcache stacks, while callers with 32-bit
> masks also impose unnecessary rbtree overhead.
> 
> In such cases, let's try a bit harder to satisfy the allocation locally
> first - scanning the whole stack should still be relatively inexpensive.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> 
> v2: There's no need for a 'proper' stack rotation
> 
>  drivers/iommu/iova.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)

Thanks, applied the series.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web