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

2016-07-19 Thread 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 
> > > Cc: Ankitprasad Sharma 
> > > Cc: Tvrtko Ursulin  > 
> > Reviewed-by: Daniel Vetter 
> 
> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2016-07-19 Thread Chris Wilson
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 
> > Cc: Ankitprasad Sharma 
> > Cc: Tvrtko Ursulin  
> Reviewed-by: Daniel Vetter 

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?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2016-07-19 Thread Chris Wilson
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 
> > Cc: Ankitprasad Sharma 
> > Cc: Tvrtko Ursulin  
> Reviewed-by: Daniel Vetter 
> 
> Aside: Anything anywhere in the pipeline to make gtt mmap more robust for
> ENOSPC?

Yes. They were on the list beginning of last year

Fence tracking gets moved to the vma (that tides up some ringbuffer and
execbuf logic, including fixing up some failure cases there) and in the
process that enables us to support partial tiled faulting as well as
fixup the current breakage. About 120 patches in.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2016-07-18 Thread Daniel Vetter
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 
> Cc: Ankitprasad Sharma 
> Cc: Tvrtko Ursulin 

Aside: Anything anywhere in the pipeline to make gtt mmap more robust for
ENOSPC?
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 4644a7e67cf6..e37f73d3965c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1306,7 +1306,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
> *data,
>* textures). Fallback to the shmem path in that case. */
>   }
>  
> - if (ret == -EFAULT) {
> + if (ret == -EFAULT || ret == -ENOSPC) {
>   if (obj->phys_handle)
>   ret = i915_gem_phys_pwrite(obj, args, file);
>   else if (i915_gem_object_has_struct_page(obj))
> -- 
> 2.8.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2016-07-16 Thread Chris Wilson
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 
Cc: Ankitprasad Sharma 
Cc: Tvrtko Ursulin phys_handle)
ret = i915_gem_phys_pwrite(obj, args, file);
else if (i915_gem_object_has_struct_page(obj))
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx