[PATCH v2 1/2] drm/i915: Do an unlocked wait before set-cache-level ioctl

[PATCH v2 1/2] drm/i915: Do an unlocked wait before set-cache-level ioctl

[Chris Wilson]

Since a change in cache level is likely to trigger an unbind, avoid
waiting under the mutex by preemptively doing an unlocked wait.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem.c | 29 +++++++++++++++++++----------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c1c2765bb8d0..0926c291404c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3384,7 +3384,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
 	struct drm_i915_gem_caching *args = data;
 	struct drm_i915_gem_object *obj;
 	enum i915_cache_level level;
-	int ret;
+	int ret = 0;
 
 	switch (args->caching) {
 	case I915_CACHING_NONE:
@@ -3409,20 +3409,29 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
 		return -EINVAL;
 	}
 
-	ret = i915_mutex_lock_interruptible(dev);
+	obj = i915_gem_object_lookup(file, args->handle);
+	if (!obj)
+		return -ENOENT;
+
+	if (obj->cache_level == level)
+		goto out;
+
+	ret = i915_gem_object_wait(obj,
+				   I915_WAIT_INTERRUPTIBLE,
+				   MAX_SCHEDULE_TIMEOUT,
+				   to_rps_client(file));
 	if (ret)
-		return ret;
+		goto out;
 
-	obj = i915_gem_object_lookup(file, args->handle);
-	if (!obj) {
-		ret = -ENOENT;
-		goto unlock;
-	}
+	ret = i915_mutex_lock_interruptible(dev);
+	if (ret)
+		goto out;
 
 	ret = i915_gem_object_set_cache_level(obj, level);
-	i915_gem_object_put(obj);
-unlock:
 	mutex_unlock(&dev->struct_mutex);
+
+out:
+	i915_gem_object_put(obj);
 	return ret;
 }
 
-- 
2.11.0

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

[PATCH v2 2/2] drm/i915: Priority boost for locked waits

[Chris Wilson]

We always try to do an unlocked wait before resorting to having a
blocking wait under the mutex - so we very rarely have to sleep under
the struct_mutex. However, when we do we want that wait to be as short
as possible as the struct_mutex is our BKL that will stall the driver and
all clients.

There should be no impact for all typical workloads.

v2: Move down a layer to apply to all waits.
v3: Make the priority boost explicit. This makes the paths where we want
boosting under the mutex clear and prevents boosting priority uselessly
for when we are waiting for idle.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_gem.c         | 10 +++++++++-
 drivers/gpu/drm/i915/i915_gem_request.c | 10 ++++++++++
 drivers/gpu/drm/i915/i915_gem_request.h |  7 +++++--
 drivers/gpu/drm/i915/intel_ringbuffer.c |  4 +++-
 4 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0926c291404c..1f53a2a46602 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -330,6 +330,7 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj)
 	ret = i915_gem_object_wait(obj,
 				   I915_WAIT_INTERRUPTIBLE |
 				   I915_WAIT_LOCKED |
+				   I915_WAIT_PRIORITY |
 				   I915_WAIT_ALL,
 				   MAX_SCHEDULE_TIMEOUT,
 				   NULL);
@@ -755,7 +756,8 @@ int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj,
 
 	ret = i915_gem_object_wait(obj,
 				   I915_WAIT_INTERRUPTIBLE |
-				   I915_WAIT_LOCKED,
+				   I915_WAIT_LOCKED |
+				   I915_WAIT_PRIORITY,
 				   MAX_SCHEDULE_TIMEOUT,
 				   NULL);
 	if (ret)
@@ -806,6 +808,7 @@ int i915_gem_obj_prepare_shmem_write(struct drm_i915_gem_object *obj,
 	ret = i915_gem_object_wait(obj,
 				   I915_WAIT_INTERRUPTIBLE |
 				   I915_WAIT_LOCKED |
+				   I915_WAIT_PRIORITY |
 				   I915_WAIT_ALL,
 				   MAX_SCHEDULE_TIMEOUT,
 				   NULL);
@@ -3073,6 +3076,8 @@ int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int flags)
 {
 	int ret;
 
+	GEM_BUG_ON(flags & I915_WAIT_PRIORITY);
+
 	if (flags & I915_WAIT_LOCKED) {
 		struct i915_gem_timeline *tl;
 
@@ -3162,6 +3167,7 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
 	ret = i915_gem_object_wait(obj,
 				   I915_WAIT_INTERRUPTIBLE |
 				   I915_WAIT_LOCKED |
+				   I915_WAIT_PRIORITY |
 				   (write ? I915_WAIT_ALL : 0),
 				   MAX_SCHEDULE_TIMEOUT,
 				   NULL);
@@ -3284,6 +3290,7 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
 		ret = i915_gem_object_wait(obj,
 					   I915_WAIT_INTERRUPTIBLE |
 					   I915_WAIT_LOCKED |
+					   I915_WAIT_PRIORITY |
 					   I915_WAIT_ALL,
 					   MAX_SCHEDULE_TIMEOUT,
 					   NULL);
@@ -3566,6 +3573,7 @@ i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write)
 	ret = i915_gem_object_wait(obj,
 				   I915_WAIT_INTERRUPTIBLE |
 				   I915_WAIT_LOCKED |
+				   I915_WAIT_PRIORITY |
 				   (write ? I915_WAIT_ALL : 0),
 				   MAX_SCHEDULE_TIMEOUT,
 				   NULL);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
index bacb875a6ef3..1db5c1f5deb9 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1046,6 +1046,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 		   !!lockdep_is_held(&req->i915->drm.struct_mutex) !=
 		   !!(flags & I915_WAIT_LOCKED));
 #endif
+	GEM_BUG_ON((flags & I915_WAIT_PRIORITY) && !(flags & I915_WAIT_LOCKED));
 	GEM_BUG_ON(timeout < 0);
 
 	if (i915_gem_request_completed(req))
@@ -1054,6 +1055,15 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 	if (!timeout)
 		return -ETIME;
 
+	/* Very rarely do we wait whilst holding the mutex. We try to always
+	 * do an unlocked wait before using a locked wait. However, when we
+	 * have to resort to a locked wait, we want that wait to be as short
+	 * as possible as the struct_mutex is our BKL that will stall the
+	 * driver and all clients.
+	 */
+	if (flags & I915_WAIT_PRIORITY && req->engine->schedule)
+		req->engine->schedule(req, I915_PRIORITY_MAX);
+
 	trace_i915_gem_request_wait_begin(req);
 
 	add_wait_queue(&req->execute, &exec);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h b/drivers/gpu/drm/i915/i915_gem_request.h
index 316c86c98b6a..47476f5e3e5f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -297,7 +297,8 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 	__attribute__((nonnull(1)));
 #define I915_WAIT_INTERRUPTIBLE	BIT(0)
 #define I915_WAIT_LOCKED	BIT(1) /* struct_mutex held, handle GPU reset */
-#define I915_WAIT_ALL		BIT(2) /* used by i915_gem_object_wait() */
+#define I915_WAIT_PRIORITY	BIT(2) /* struct_mutex held, boost priority */
+#define I915_WAIT_ALL		BIT(3) /* used by i915_gem_object_wait() */
 
 static inline u32 intel_engine_get_seqno(struct intel_engine_cs *engine);
 
@@ -722,7 +723,9 @@ i915_gem_active_retire(struct i915_gem_active *active,
 		return 0;
 
 	ret = i915_wait_request(request,
-				I915_WAIT_INTERRUPTIBLE | I915_WAIT_LOCKED,
+				I915_WAIT_INTERRUPTIBLE |
+				I915_WAIT_LOCKED |
+				I915_WAIT_PRIORITY,
 				MAX_SCHEDULE_TIMEOUT);
 	if (ret < 0)
 		return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index cf4ec937d923..2f7651ef45d5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2158,7 +2158,9 @@ static int wait_for_space(struct drm_i915_gem_request *req, int bytes)
 		return -ENOSPC;
 
 	timeout = i915_wait_request(target,
-				    I915_WAIT_INTERRUPTIBLE | I915_WAIT_LOCKED,
+				    I915_WAIT_INTERRUPTIBLE |
+				    I915_WAIT_LOCKED |
+				    I915_WAIT_PRIORITY,
 				    MAX_SCHEDULE_TIMEOUT);
 	if (timeout < 0)
 		return timeout;
-- 
2.11.0

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

✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Do an unlocked wait before set-cache-level ioctl

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915: Do an unlocked wait before set-cache-level ioctl
URL   : https://patchwork.freedesktop.org/series/18216/
State : success

== Summary ==

Series 18216v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/18216/revisions/1/mbox/

Test gem_busy:
        Subgroup basic-busy-default:
                fail       -> PASS       (fi-ivb-3520m)

fi-bdw-5557u     total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050     total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205     total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700     total:79   pass:66   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900     total:246  pass:218  dwarn:1   dfail:0   fail:0   skip:27 
fi-byt-n2820     total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770      total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r     total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m     total:246  pass:224  dwarn:1   dfail:0   fail:0   skip:21 
fi-ivb-3770      total:246  pass:224  dwarn:1   dfail:0   fail:0   skip:21 
fi-kbl-7500u     total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u     total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hq    total:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k     total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hq    total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m     total:246  pass:214  dwarn:1   dfail:0   fail:0   skip:31 
fi-snb-2600      total:246  pass:213  dwarn:1   dfail:0   fail:0   skip:32 

7388ba188ee967c9527fb6df4e6109845b8179ec drm-tip: 2017y-01m-19d-05h-11m-05s UTC integration manifest
4e2ba21 drm/i915: Do an unlocked wait before set-cache-level ioctl

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3542/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v2 1/2] drm/i915: Do an unlocked wait before set-cache-level ioctl

[Mika Kuoppala]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Since a change in cache level is likely to trigger an unbind, avoid
> waiting under the mutex by preemptively doing an unlocked wait.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 29 +++++++++++++++++++----------
>  1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c1c2765bb8d0..0926c291404c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3384,7 +3384,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
>  	struct drm_i915_gem_caching *args = data;
>  	struct drm_i915_gem_object *obj;
>  	enum i915_cache_level level;
> -	int ret;
> +	int ret = 0;
>  
>  	switch (args->caching) {
>  	case I915_CACHING_NONE:
> @@ -3409,20 +3409,29 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
>  		return -EINVAL;
>  	}
>  
> -	ret = i915_mutex_lock_interruptible(dev);
> +	obj = i915_gem_object_lookup(file, args->handle);
> +	if (!obj)
> +		return -ENOENT;
> +
> +	if (obj->cache_level == level)
> +		goto out;
> +
> +	ret = i915_gem_object_wait(obj,
> +				   I915_WAIT_INTERRUPTIBLE,
> +				   MAX_SCHEDULE_TIMEOUT,
> +				   to_rps_client(file));
>  	if (ret)
> -		return ret;
> +		goto out;
>  
> -	obj = i915_gem_object_lookup(file, args->handle);
> -	if (!obj) {
> -		ret = -ENOENT;
> -		goto unlock;
> -	}

Is the intent here that you just make it very likely
that the wait in set_cache_level will not trigger?

-Mika

> +	ret = i915_mutex_lock_interruptible(dev);
> +	if (ret)
> +		goto out;
>  
>  	ret = i915_gem_object_set_cache_level(obj, level);
> -	i915_gem_object_put(obj);
> -unlock:
>  	mutex_unlock(&dev->struct_mutex);
> +
> +out:
> +	i915_gem_object_put(obj);
>  	return ret;
>  }
>  
> -- 
> 2.11.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v2 1/2] drm/i915: Do an unlocked wait before set-cache-level ioctl

[Mika Kuoppala]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Since a change in cache level is likely to trigger an unbind, avoid
> waiting under the mutex by preemptively doing an unlocked wait.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 29 +++++++++++++++++++----------
>  1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c1c2765bb8d0..0926c291404c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3384,7 +3384,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
>  	struct drm_i915_gem_caching *args = data;
>  	struct drm_i915_gem_object *obj;
>  	enum i915_cache_level level;
> -	int ret;
> +	int ret = 0;
>  
>  	switch (args->caching) {
>  	case I915_CACHING_NONE:
> @@ -3409,20 +3409,29 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
>  		return -EINVAL;
>  	}
>  
> -	ret = i915_mutex_lock_interruptible(dev);
> +	obj = i915_gem_object_lookup(file, args->handle);

Does this need to be i915_gem_object_lookup_rcu?

-Mika

> +	if (!obj)
> +		return -ENOENT;
> +
> +	if (obj->cache_level == level)
> +		goto out;
> +
> +	ret = i915_gem_object_wait(obj,
> +				   I915_WAIT_INTERRUPTIBLE,
> +				   MAX_SCHEDULE_TIMEOUT,
> +				   to_rps_client(file));
>  	if (ret)
> -		return ret;
> +		goto out;
>  
> -	obj = i915_gem_object_lookup(file, args->handle);
> -	if (!obj) {
> -		ret = -ENOENT;
> -		goto unlock;
> -	}
> +	ret = i915_mutex_lock_interruptible(dev);
> +	if (ret)
> +		goto out;
>  
>  	ret = i915_gem_object_set_cache_level(obj, level);
> -	i915_gem_object_put(obj);
> -unlock:
>  	mutex_unlock(&dev->struct_mutex);
> +
> +out:
> +	i915_gem_object_put(obj);
>  	return ret;
>  }
>  
> -- 
> 2.11.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v2 1/2] drm/i915: Do an unlocked wait before set-cache-level ioctl

[Chris Wilson]

On Thu, Jan 19, 2017 at 01:36:29PM +0200, Mika Kuoppala wrote:
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > Since a change in cache level is likely to trigger an unbind, avoid
> > waiting under the mutex by preemptively doing an unlocked wait.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 29 +++++++++++++++++++----------
> >  1 file changed, 19 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index c1c2765bb8d0..0926c291404c 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3384,7 +3384,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
> >  	struct drm_i915_gem_caching *args = data;
> >  	struct drm_i915_gem_object *obj;
> >  	enum i915_cache_level level;
> > -	int ret;
> > +	int ret = 0;
> >  
> >  	switch (args->caching) {
> >  	case I915_CACHING_NONE:
> > @@ -3409,20 +3409,29 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
> >  		return -EINVAL;
> >  	}
> >  
> > -	ret = i915_mutex_lock_interruptible(dev);
> > +	obj = i915_gem_object_lookup(file, args->handle);
> > +	if (!obj)
> > +		return -ENOENT;
> > +
> > +	if (obj->cache_level == level)
> > +		goto out;
> > +
> > +	ret = i915_gem_object_wait(obj,
> > +				   I915_WAIT_INTERRUPTIBLE,
> > +				   MAX_SCHEDULE_TIMEOUT,
> > +				   to_rps_client(file));
> >  	if (ret)
> > -		return ret;
> > +		goto out;
> >  
> > -	obj = i915_gem_object_lookup(file, args->handle);
> > -	if (!obj) {
> > -		ret = -ENOENT;
> > -		goto unlock;
> > -	}
> 
> Is the intent here that you just make it very likely
> that the wait in set_cache_level will not trigger?

Yes. We don't remove it, since we need it to ensure correctness, but we
prefer to do the waiting without holding any lock.
-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: [PATCH v2 1/2] drm/i915: Do an unlocked wait before set-cache-level ioctl

[Chris Wilson]

On Thu, Jan 19, 2017 at 01:42:47PM +0200, Mika Kuoppala wrote:
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > Since a change in cache level is likely to trigger an unbind, avoid
> > waiting under the mutex by preemptively doing an unlocked wait.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 29 +++++++++++++++++++----------
> >  1 file changed, 19 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index c1c2765bb8d0..0926c291404c 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3384,7 +3384,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
> >  	struct drm_i915_gem_caching *args = data;
> >  	struct drm_i915_gem_object *obj;
> >  	enum i915_cache_level level;
> > -	int ret;
> > +	int ret = 0;
> >  
> >  	switch (args->caching) {
> >  	case I915_CACHING_NONE:
> > @@ -3409,20 +3409,29 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
> >  		return -EINVAL;
> >  	}
> >  
> > -	ret = i915_mutex_lock_interruptible(dev);
> > +	obj = i915_gem_object_lookup(file, args->handle);
> 
> Does this need to be i915_gem_object_lookup_rcu?

No. That's a special case for when the caller knows it is using RCU for
the entire duration of the access and so doesn't need to acquire a
reference to the object.
-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: [PATCH v2 1/2] drm/i915: Do an unlocked wait before set-cache-level ioctl

[Mika Kuoppala]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> On Thu, Jan 19, 2017 at 01:42:47PM +0200, Mika Kuoppala wrote:
>> Chris Wilson <chris@chris-wilson.co.uk> writes:
>> 
>> > Since a change in cache level is likely to trigger an unbind, avoid
>> > waiting under the mutex by preemptively doing an unlocked wait.
>> >
>> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> > ---
>> >  drivers/gpu/drm/i915/i915_gem.c | 29 +++++++++++++++++++----------
>> >  1 file changed, 19 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>> > index c1c2765bb8d0..0926c291404c 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem.c
>> > @@ -3384,7 +3384,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
>> >  	struct drm_i915_gem_caching *args = data;
>> >  	struct drm_i915_gem_object *obj;
>> >  	enum i915_cache_level level;
>> > -	int ret;
>> > +	int ret = 0;
>> >  
>> >  	switch (args->caching) {
>> >  	case I915_CACHING_NONE:
>> > @@ -3409,20 +3409,29 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
>> >  		return -EINVAL;
>> >  	}
>> >  
>> > -	ret = i915_mutex_lock_interruptible(dev);
>> > +	obj = i915_gem_object_lookup(file, args->handle);
>> 
>> Does this need to be i915_gem_object_lookup_rcu?
>
> No. That's a special case for when the caller knows it is using RCU for
> the entire duration of the access and so doesn't need to acquire a
> reference to the object.

get_caching distracted me and I got it backwards. Actually looking
at the i915_gem_object_lookup would have saved a mail.

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

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