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@xxxxxxxxxxxxxxxxxx>
> > > Cc: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx
> >
> > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
>
> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
