All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brice Goglin <Brice.Goglin@inria.fr>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] x86: gup_fast() batch limit
Date: Wed, 24 Jun 2009 15:46:10 +0200	[thread overview]
Message-ID: <4A422E22.6020801@inria.fr> (raw)
In-Reply-To: <200904022219.53949.nickpiggin@yahoo.com.au>

Any news about this patch?

Brice



Nick Piggin wrote:
> On Saturday 28 March 2009 23:46:14 Peter Zijlstra wrote:
>   
>> On Sat, 2009-03-28 at 13:22 +0100, Peter Zijlstra wrote:
>>     
>>> I'm not really trusting my brain today, but something like the below
>>> should work I think.
>>>
>>> Nick, any thoughts?
>>>
>>> Not-Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>> ---
>>>  arch/x86/mm/gup.c |   24 +++++++++++++++++++++---
>>>  1 files changed, 21 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
>>> index be54176..4ded5c3 100644
>>> --- a/arch/x86/mm/gup.c
>>> +++ b/arch/x86/mm/gup.c
>>> @@ -11,6 +11,8 @@
>>>
>>>  #include <asm/pgtable.h>
>>>
>>> +#define GUP_BATCH	32
>>> +
>>>  static inline pte_t gup_get_pte(pte_t *ptep)
>>>  {
>>>  #ifndef CONFIG_X86_PAE
>>> @@ -91,7 +93,8 @@ static noinline int gup_pte_range(pmd_t pmd, unsigned
>>> long addr, get_page(page);
>>>  		pages[*nr] = page;
>>>  		(*nr)++;
>>> -
>>> +		if (*nr > GUP_BATCH)
>>> +			break;
>>>  	} while (ptep++, addr += PAGE_SIZE, addr != end);
>>>  	pte_unmap(ptep - 1);
>>>
>>> @@ -157,6 +160,8 @@ static int gup_pmd_range(pud_t pud, unsigned long
>>> addr, unsigned long end, if (!gup_pte_range(pmd, addr, next, write,
>>> pages, nr))
>>>  				return 0;
>>>  		}
>>> +		if (*nr > GUP_BATCH)
>>> +			break;
>>>  	} while (pmdp++, addr = next, addr != end);
>>>
>>>  	return 1;
>>> @@ -214,6 +219,8 @@ static int gup_pud_range(pgd_t pgd, unsigned long
>>> addr, unsigned long end, if (!gup_pmd_range(pud, addr, next, write,
>>> pages, nr))
>>>  				return 0;
>>>  		}
>>> +		if (*nr > GUP_BATCH)
>>> +			break;
>>>  	} while (pudp++, addr = next, addr != end);
>>>
>>>  	return 1;
>>> @@ -226,7 +233,7 @@ int get_user_pages_fast(unsigned long start, int
>>> nr_pages, int write, unsigned long addr, len, end;
>>>  	unsigned long next;
>>>  	pgd_t *pgdp;
>>> -	int nr = 0;
>>> +	int batch = 0, nr = 0;
>>>
>>>  	start &= PAGE_MASK;
>>>  	addr = start;
>>> @@ -254,6 +261,7 @@ int get_user_pages_fast(unsigned long start, int
>>> nr_pages, int write, * (which we do on x86, with the above PAE
>>> exception), we can follow the * address down to the the page and take a
>>> ref on it.
>>>  	 */
>>> +again:
>>>  	local_irq_disable();
>>>  	pgdp = pgd_offset(mm, addr);
>>>  	do {
>>> @@ -262,11 +270,21 @@ int get_user_pages_fast(unsigned long start, int
>>> nr_pages, int write, next = pgd_addr_end(addr, end);
>>>  		if (pgd_none(pgd))
>>>  			goto slow;
>>> -		if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
>>> +		if (!gup_pud_range(pgd, addr, next, write, pages, &batch))
>>>  			goto slow;
>>> +		if (batch > GUP_BATCH) {
>>> +			local_irq_enable();
>>> +			addr += batch << PAGE_SHIFT;
>>> +			nr += batch;
>>> +			batch = 0;
>>> +			if (addr != end)
>>> +				goto again;
>>> +		}
>>>  	} while (pgdp++, addr = next, addr != end);
>>>  	local_irq_enable();
>>>
>>> +	nr += batch;
>>> +
>>>  	VM_BUG_ON(nr != (end - start) >> PAGE_SHIFT);
>>>  	return nr;
>>>       
>> Would also need the following bit:
>>
>> @@ -274,6 +292,7 @@ int get_user_pages_fast(unsigned long start, int
>> nr_pages, int write, int ret;
>>
>>  slow:
>> +		nr += batch;
>>  		local_irq_enable();
>>  slow_irqon:
>>  		/* Try to get the remaining pages with get_user_pages */
>>     
>
>
> Yeah something like this would be fine (and welcome). And we can
> remove the XXX comment in there too. I would suggest 64 being a
> reasonable value simply because that's what direct IO does.
>
> Implementation-wise, why not just break "len" into chunks in the
> top level function rather than add branches all down the call
> chain?
>   


  reply	other threads:[~2009-06-24 13:46 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                       ` Brice Goglin [this message]
2009-06-24 17:07                         ` [RFC] x86: gup_fast() batch limit Peter Zijlstra
2009-06-24 19:55                         ` Peter Zijlstra

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=4A422E22.6020801@inria.fr \
    --to=brice.goglin@inria.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=peterz@infradead.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.