[Intel-gfx] [PATCH] drm/i915: Handle ENOSPC after failing to insert a mappable node

[Daniel Vetter]

On Tue, Jul 19, 2016 at 09:28:34AM +0100, Chris Wilson wrote:
> On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
> > On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote:
> > > Even after adding individual page support for GTT mmaping, we can still
> > > fail to find any space within the mappable region, and
> > > drm_mm_insert_node() will then report ENOSPC. We have to then handle
> > > this error by using the shmem access to the pages.
> > > 
> > > Fixes: b50a53715f09 ("drm/i915: Support for pread/pwrite ... objects")
> > > Testcase: igt/gem_concurrent_blit
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Ankitprasad Sharma <ankitprasad.r.sharma at intel.com>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com
> > 
> > Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> 
> Thanks for the review, pushed.
> 
> Ideas for how we can stress this a bit directly than
> gem_concurrent_blit?
> 
> We need to have many threads all pinning and then hitting the slow path
> in the read (thus allowing another thread to come in and fail to claim
> some aperture space for itself). Tricksy.
> 
> Hmm, how about fault-injection under I915_DEBUG?

I think fault injection is the only feasible way for such a fallback for a
fallback case. We need to entirely exhaust mmap gtt afaics at aleast.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch