[RFC] x86: gup_fast() batch limit (was: DRM lock ordering fix series)

2009-03-28 Thread Peter Zijlstra
On Sat, 2009-03-28 at 11:48 +0100, Peter Zijlstra wrote: > On Sat, 2009-03-28 at 09:46 +0100, Brice Goglin wrote: > > Peter Zijlstra wrote: > > > Also note that doing large gup() with gup_fast() will be undesirable due > > > to it disabling IRQs. So iterating say several MB worth of pages will > >

Re: [PATCH 1/6] drm/i915: Fix lock order reversal in GTT pwrite path.

2009-03-28 Thread Peter Zijlstra
On Thu, 2009-03-26 at 17:43 -0700, Jesse Barnes wrote: > On Wed, 25 Mar 2009 14:45:05 -0700 > Eric Anholt wrote: > > > Since the pagefault path determines that the lock order we use has to > > be mmap_sem -> struct_mutex, we can't allow page faults to occur > > while the struct_mutex is held. To

Re: DRM lock ordering fix series

2009-03-28 Thread Peter Zijlstra
On Fri, 2009-03-27 at 13:10 -0700, Eric Anholt wrote: > On Fri, 2009-03-27 at 19:10 +0100, Andi Kleen wrote: > > On Fri, Mar 27, 2009 at 09:36:45AM -0700, Eric Anholt wrote: > > > > > You are aware that there is a fast path now (get_user_pages_fast) > > > > > which > > > > > is significantly faste

Re: DRM lock ordering fix series

2009-03-28 Thread Peter Zijlstra
On Sat, 2009-03-28 at 01:58 +0100, Peter Zijlstra wrote: > > OK. I'm not too excited here -- 10% of 2% of the CPU time doesn't get > > me to the 10% loss that the slow path added up to. Most of the cost is > > in k{un,}map_atomic of the returned pages. > > Also note that doing large gup() wit

Re: [RFC] x86: gup_fast() batch limit (was: DRM lock ordering fix series)

2009-03-28 Thread Peter Zijlstra
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 > --- > arch/x86/mm/gup.c | 24 +--- > 1 files changed, 21

Re: DRM lock ordering fix series

2009-03-28 Thread Brice Goglin
Peter Zijlstra wrote: > Also note that doing large gup() with gup_fast() will be undesirable due > to it disabling IRQs. So iterating say several MB worth of pages will > hurt like crazy. Currently all gup_fast() users do a single page lookup. > In 2.6.29, fs/bio.c:955, fs/direct-io.c:153 and f

Re: DRM lock ordering fix series

2009-03-28 Thread Peter Zijlstra
On Sat, 2009-03-28 at 09:46 +0100, Brice Goglin wrote: > Peter Zijlstra wrote: > > Also note that doing large gup() with gup_fast() will be undesirable due > > to it disabling IRQs. So iterating say several MB worth of pages will > > hurt like crazy. Currently all gup_fast() users do a single page