Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1741406 > unrolled thread
| Started by | Robin Murphy <robin.murphy@arm.com> |
|---|---|
| First post | 2017-09-28 12:40 +0200 |
| Last post | 2017-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.
[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
| From | Robin Murphy <robin.murphy@arm.com> |
|---|---|
| Date | 2017-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]
| From | Joerg Roedel <joro@8bytes.org> |
|---|---|
| Date | 2017-09-28 15:50 +0200 |
| Subject | Re: [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