[Intel-gfx] [PATCH 17/42] drm/i915: Pass around sg_table to get_pages/put_pages backend

[Chris Wilson]

On Mon, Oct 17, 2016 at 11:52:27AM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 10:43, Chris Wilson wrote:
> >On Fri, Oct 14, 2016 at 10:28:42AM +0100, Tvrtko Ursulin wrote:
> >>  diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> >>  index 3c22d49005fe..271e63c8f037 100644
> >>  --- a/drivers/gpu/drm/i915/i915_drv.h
> >>  +++ b/drivers/gpu/drm/i915/i915_drv.h
> >>  @@ -2175,8 +2175,8 @@ struct drm_i915_gem_object_ops {
> >>           * being released or under memory pressure (where we attempt to
> >>           * reap pages for the shrinker).
> >>           */
> >>  -       int (*get_pages)(struct drm_i915_gem_object *);
> >>  -       void (*put_pages)(struct drm_i915_gem_object *);
> >>  +       struct sg_table *(*get_pages)(struct drm_i915_gem_object *);
> >>  +       void (*put_pages)(struct drm_i915_gem_object *, struct sg_table *);
> >>
> >>    Idea is that put_pages vfunc does not need struct mutex?  Or it acquires
> >>    it on demand inside it, which means struct mutex will nest inside the
> >>    mm.lock?
> >Right, it loses the mutex within get/put pages and I am no longer
> >concerned about the number of workers. Though that is mainly because of
> >another patch to improve execbuf + userptr workloads.
> 
> Is that other patch before or after this one? Or in a different
> series altogether? In any case, why should this change be in this
> patch, especially when it is not commented anywhere?

Actually, it follows from 

commit 364c8172edb5ff0b4650bbd4c45eaab46b84b008
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Thu Aug 18 17:16:58 2016 +0100

    drm/i915/userptr: Make gup errors stickier

which was the prelude to the patch I was thinking of. The current code
already doesn't use more than one worker simultaneously.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre