From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH] drm/i915: Use rcu instead of stop_machine
Date: Thu, 5 Oct 2017 15:55:19 +0100 [thread overview]
Message-ID: <cc5269d0-b78c-055f-7a71-e437c1d33236@linux.intel.com> (raw)
In-Reply-To: <20171005140948.12129-1-daniel.vetter@ffwll.ch>
On 05/10/2017 15:09, Daniel Vetter wrote:
> stop_machine is not really a locking primitive we should use, except
> when the hw folks tell us the hw is broken and that's the only way to
> work around it.
>
> This patch here is just a suggestion for how to fix it up, possible
> changes needed to make it actually work:
>
> - Set the nop_submit_request first for _all_ engines, before
> proceeding.
>
> - Make sure engine->cancel_requests copes with the possibility that
> not all tests have consistently used the new or old version. I dont
> think this is a problem, since the same can happen really with the
> stop_machine() locking - stop_machine also doesn't give you any kind
> of global ordering against other cpu threads, it just makes them
> stop.
>
> This patch tries to address the locking snafu from
>
> commit 20e4933c478a1ca694b38fa4ac44d99e659941f5
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date: Tue Nov 22 14:41:21 2016 +0000
>
> drm/i915: Stop the machine as we install the wedged submit_request handler
>
> Chris said parts of the reasons for going with stop_machine() was that
> it's no overhead for the fast-path. But these callbacks use irqsave
> spinlocks and do a bunch of MMIO, and rcu_read_lock is _real_ fast.
>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 18 +++++-------------
> drivers/gpu/drm/i915/i915_gem_request.c | 2 ++
> drivers/gpu/drm/i915/selftests/i915_gem_request.c | 2 ++
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index ab8c6946fea4..0b260e576b4b 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3022,13 +3022,13 @@ static void nop_submit_request(struct drm_i915_gem_request *request)
>
> static void engine_set_wedged(struct intel_engine_cs *engine)
> {
> + engine->submit_request = nop_submit_request;
Should this be rcu_assign_pointer?
> +
> /* We need to be sure that no thread is running the old callback as
> * we install the nop handler (otherwise we would submit a request
> - * to hardware that will never complete). In order to prevent this
> - * race, we wait until the machine is idle before making the swap
> - * (using stop_machine()).
> + * to hardware that will never complete).
> */
> - engine->submit_request = nop_submit_request;
> + synchronize_rcu();
Consumers of this are running in irq disabled or softirq. Does this mean
we would need synchronize_rcu_bh? Would either guarantee all tasklets
and irq handlers have exited?
> /* Mark all executing requests as skipped */
> engine->cancel_requests(engine);
> @@ -3041,9 +3041,8 @@ static void engine_set_wedged(struct intel_engine_cs *engine)
> intel_engine_last_submit(engine));
> }
>
> -static int __i915_gem_set_wedged_BKL(void *data)
> +void i915_gem_set_wedged(struct drm_i915_private *i915)
> {
> - struct drm_i915_private *i915 = data;
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
>
> @@ -3052,13 +3051,6 @@ static int __i915_gem_set_wedged_BKL(void *data)
>
> set_bit(I915_WEDGED, &i915->gpu_error.flags);
> wake_up_all(&i915->gpu_error.reset_queue);
> -
> - return 0;
> -}
> -
> -void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
> -{
> - stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
> }
>
> bool i915_gem_unset_wedged(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
> index b100b38f1dd2..ef78a85cb845 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -556,7 +556,9 @@ submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
> switch (state) {
> case FENCE_COMPLETE:
> trace_i915_gem_request_submit(request);
> + rcu_read_lock();
> request->engine->submit_request(request);
> + rcu_read_unlock();
And _bh for these? Although this already runs with preemption off, but I
guess it is good for documentation.
Regards,
Tvrtko
> break;
>
> case FENCE_FREE:
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_request.c b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
> index 78b9f811707f..a999161e8db1 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
> @@ -215,7 +215,9 @@ static int igt_request_rewind(void *arg)
> }
> i915_gem_request_get(vip);
> i915_add_request(vip);
> + rcu_read_lock();
> request->engine->submit_request(request);
> + rcu_read_unlock();
>
> mutex_unlock(&i915->drm.struct_mutex);
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-10-05 14:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 14:09 [PATCH] drm/i915: Use rcu instead of stop_machine Daniel Vetter
2017-10-05 14:30 ` Chris Wilson
2017-10-05 16:12 ` Daniel Vetter
2017-10-06 8:42 ` Chris Wilson
2017-10-06 8:56 ` Daniel Vetter
2017-10-06 10:01 ` Thomas Gleixner
2017-10-05 14:55 ` Tvrtko Ursulin [this message]
2017-10-05 16:24 ` Daniel Vetter
2017-10-06 8:30 ` Tvrtko Ursulin
2017-10-06 8:49 ` Daniel Vetter
2017-10-06 8:47 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-10-06 9:50 ` ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cc5269d0-b78c-055f-7a71-e437c1d33236@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mika.kuoppala@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox