All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Brice Goglin <Brice.Goglin@inria.fr>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: [RFC] x86: gup_fast() batch limit
Date: Wed, 24 Jun 2009 21:55:29 +0200	[thread overview]
Message-ID: <1245873329.1658.79.camel@laptop> (raw)
In-Reply-To: <4A422E22.6020801@inria.fr>

On Wed, 2009-06-24 at 15:46 +0200, Brice Goglin wrote:
> Any news about this patch?

Compile tested on x86_64 and ppc64.

---
Implement the batching mentioned in the gup_fast comment.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
 arch/powerpc/mm/gup.c |   28 +++++++++++++---------------
 arch/x86/mm/gup.c     |   46 ++++++++++++++++++++--------------------------
 2 files changed, 33 insertions(+), 41 deletions(-)

diff --git a/arch/powerpc/mm/gup.c b/arch/powerpc/mm/gup.c
index bc400c7..cf535bf 100644
--- a/arch/powerpc/mm/gup.c
+++ b/arch/powerpc/mm/gup.c
@@ -146,11 +146,13 @@ static int gup_pud_range(pgd_t pgd, unsigned long addr, unsigned long end,
 	return 1;
 }
 
+#define CHUNK_SIZE (64 * PAGE_SIZE)
+
 int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 			struct page **pages)
 {
 	struct mm_struct *mm = current->mm;
-	unsigned long addr, len, end;
+	unsigned long addr, len, end, chunk;
 	unsigned long next;
 	pgd_t *pgdp;
 	int nr = 0;
@@ -191,16 +193,9 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 	}
 #endif /* CONFIG_HUGETLB_PAGE */
 
-	/*
-	 * XXX: batch / limit 'nr', to avoid large irq off latency
-	 * needs some instrumenting to determine the common sizes used by
-	 * important workloads (eg. DB2), and whether limiting the batch size
-	 * will decrease performance.
-	 *
-	 * It seems like we're in the clear for the moment. Direct-IO is
-	 * the main guy that batches up lots of get_user_pages, and even
-	 * they are limited to 64-at-a-time which is not so many.
-	 */
+again:
+	chunk = min(addr + CHUNK_SIZE, end);
+
 	/*
 	 * This doesn't prevent pagetable teardown, but does prevent
 	 * the pagetables from being freed on powerpc.
@@ -235,10 +230,10 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 			VM_BUG_ON(shift != mmu_psize_defs[get_slice_psize(mm, a)].shift);
 			ptep = huge_pte_offset(mm, a);
 			pr_debug(" %016lx: huge ptep %p\n", a, ptep);
-			if (!ptep || !gup_huge_pte(ptep, hstate, &a, end, write, pages,
+			if (!ptep || !gup_huge_pte(ptep, hstate, &a, chunk, write, pages,
 						   &nr))
 				goto slow;
-		} while (a != end);
+		} while (a != chunk);
 	} else
 #endif /* CONFIG_HUGETLB_PAGE */
 	{
@@ -251,15 +246,18 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 #endif
 			pr_debug("  %016lx: normal pgd %p\n", addr,
 				 (void *)pgd_val(pgd));
-			next = pgd_addr_end(addr, end);
+			next = pgd_addr_end(addr, chunk);
 			if (pgd_none(pgd))
 				goto slow;
 			if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
 				goto slow;
-		} while (pgdp++, addr = next, addr != end);
+		} while (pgdp++, addr = next, addr != chunk);
 	}
 	local_irq_enable();
 
+	if (addr != end)
+		goto again;
+
 	VM_BUG_ON(nr != (end - start) >> PAGE_SHIFT);
 	return nr;
 
diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
index 71da1bc..9e0552b 100644
--- a/arch/x86/mm/gup.c
+++ b/arch/x86/mm/gup.c
@@ -219,6 +219,8 @@ static int gup_pud_range(pgd_t pgd, unsigned long addr, unsigned long end,
 	return 1;
 }
 
+#define CHUNK_SIZE	(64 * PAGE_SIZE)
+
 /*
  * Like get_user_pages_fast() except its IRQ-safe in that it won't fall
  * back to the regular GUP.
@@ -227,7 +229,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
 			  struct page **pages)
 {
 	struct mm_struct *mm = current->mm;
-	unsigned long addr, len, end;
+	unsigned long addr, len, end, chunk;
 	unsigned long next;
 	unsigned long flags;
 	pgd_t *pgdp;
@@ -241,16 +243,9 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
 					(void __user *)start, len)))
 		return 0;
 
-	/*
-	 * XXX: batch / limit 'nr', to avoid large irq off latency
-	 * needs some instrumenting to determine the common sizes used by
-	 * important workloads (eg. DB2), and whether limiting the batch size
-	 * will decrease performance.
-	 *
-	 * It seems like we're in the clear for the moment. Direct-IO is
-	 * the main guy that batches up lots of get_user_pages, and even
-	 * they are limited to 64-at-a-time which is not so many.
-	 */
+again:
+	chunk = min(addr + CHUNK_SIZE, end);
+
 	/*
 	 * This doesn't prevent pagetable teardown, but does prevent
 	 * the pagetables and pages from being freed on x86.
@@ -264,14 +259,17 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
 	do {
 		pgd_t pgd = *pgdp;
 
-		next = pgd_addr_end(addr, end);
+		next = pgd_addr_end(addr, chunk);
 		if (pgd_none(pgd))
 			break;
 		if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
 			break;
-	} while (pgdp++, addr = next, addr != end);
+	} while (pgdp++, addr = next, addr != chunk);
 	local_irq_restore(flags);
 
+	if (addr != end)
+		goto again;
+
 	return nr;
 }
 
@@ -295,7 +293,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 			struct page **pages)
 {
 	struct mm_struct *mm = current->mm;
-	unsigned long addr, len, end;
+	unsigned long addr, len, end, chunk;
 	unsigned long next;
 	pgd_t *pgdp;
 	int nr = 0;
@@ -313,16 +311,9 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 		goto slow_irqon;
 #endif
 
-	/*
-	 * XXX: batch / limit 'nr', to avoid large irq off latency
-	 * needs some instrumenting to determine the common sizes used by
-	 * important workloads (eg. DB2), and whether limiting the batch size
-	 * will decrease performance.
-	 *
-	 * It seems like we're in the clear for the moment. Direct-IO is
-	 * the main guy that batches up lots of get_user_pages, and even
-	 * they are limited to 64-at-a-time which is not so many.
-	 */
+again:
+	chunk = min(addr + CHUNK_SIZE, end);
+
 	/*
 	 * This doesn't prevent pagetable teardown, but does prevent
 	 * the pagetables and pages from being freed on x86.
@@ -336,14 +327,17 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 	do {
 		pgd_t pgd = *pgdp;
 
-		next = pgd_addr_end(addr, end);
+		next = pgd_addr_end(addr, chunk);
 		if (pgd_none(pgd))
 			goto slow;
 		if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
 			goto slow;
-	} while (pgdp++, addr = next, addr != end);
+	} while (pgdp++, addr = next, addr != chunk);
 	local_irq_enable();
 
+	if (addr != end)
+		goto again;
+
 	VM_BUG_ON(nr != (end - start) >> PAGE_SHIFT);
 	return nr;
 



      parent reply	other threads:[~2009-06-24 19:55 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-25 21:45 DRM lock ordering fix series Eric Anholt
2009-03-25 21:45 ` [PATCH 1/6] drm/i915: Fix lock order reversal in GTT pwrite path Eric Anholt
2009-03-25 21:45   ` [PATCH 2/6] drm/i915: Make GEM object's page lists refcounted instead of get/free Eric Anholt
2009-03-25 21:45     ` [PATCH 3/6] drm/i915: Fix lock order reversal in shmem pwrite path Eric Anholt
2009-03-25 21:45       ` [PATCH 4/6] drm/i915: Fix lock order reversal in shmem pread path Eric Anholt
2009-03-25 21:45         ` [PATCH 5/6] drm/i915: Fix lock order reversal with cliprects and cmdbuf in non-DRI2 paths Eric Anholt
2009-03-25 21:45           ` [PATCH 6/6] drm/i915: Fix lock order reversal in GEM relocation entry copying Eric Anholt
2009-03-30 10:00             ` [PATCH 6/6] drm/i915: Fix lock order reversal in GEM relocation entry copying. -- makes X hang Florian Mickler
2009-03-31 19:36               ` Eric Anholt
2009-04-01  0:12                 ` Florian Mickler
2009-03-27  0:52           ` [PATCH 5/6] drm/i915: Fix lock order reversal with cliprects and cmdbuf in non-DRI2 paths Jesse Barnes
2009-03-25 23:30         ` [PATCH 4/6] drm/i915: Fix lock order reversal in shmem pread path Dave Airlie
2009-03-26  4:03           ` Keith Packard
2009-03-27  0:50         ` Jesse Barnes
2009-03-27  0:50       ` [PATCH 3/6] drm/i915: Fix lock order reversal in shmem pwrite path Jesse Barnes
2009-03-25 22:52     ` [PATCH 2/6] drm/i915: Make GEM object's page lists refcounted instead of get/free Dave Airlie
2009-03-26 19:59       ` Eric Anholt
2009-03-27  0:47     ` Jesse Barnes
2009-03-27  0:43   ` [PATCH 1/6] drm/i915: Fix lock order reversal in GTT pwrite path Jesse Barnes
2009-03-27 16:56     ` Eric Anholt
2009-03-27 17:07       ` Jesse Barnes
2009-03-28  0:54     ` Peter Zijlstra
2009-03-28  2:35       ` Jesse Barnes
2009-03-28  5:22         ` Dave Airlie
2009-03-27  9:34 ` DRM lock ordering fix series Andi Kleen
2009-03-27 16:19   ` Eric Anholt
2009-03-27 16:36     ` Eric Anholt
2009-03-27 18:10       ` Andi Kleen
2009-03-27 20:10         ` Eric Anholt
2009-03-27 21:05           ` Andi Kleen
2009-03-28  0:58           ` Peter Zijlstra
2009-03-28  1:29             ` Peter Zijlstra
2009-03-30  6:29               ` Eric Anholt
2009-03-28  8:46             ` Brice Goglin
2009-03-28 10:48               ` Peter Zijlstra
2009-03-28 12:22                 ` [RFC] x86: gup_fast() batch limit (was: DRM lock ordering fix series) Peter Zijlstra
2009-03-28 12:46                   ` Peter Zijlstra
2009-04-02 11:19                     ` Nick Piggin
2009-06-24 13:46                       ` [RFC] x86: gup_fast() batch limit Brice Goglin
2009-06-24 17:07                         ` Peter Zijlstra
2009-06-24 19:55                         ` Peter Zijlstra [this message]

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=1245873329.1658.79.camel@laptop \
    --to=peterz@infradead.org \
    --cc=Brice.Goglin@inria.fr \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=paulus@samba.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.