From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 12/22] drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker
Date: Thu, 08 Sep 2016 13:52:21 +0300 [thread overview]
Message-ID: <87zini7jfe.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20160907144516.29495-12-chris@chris-wilson.co.uk>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> Since we have a cooperative mode now with a direct reset, we can avoid
> the contention on struct_mutex and instead try then sleep on the
> I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is
> cleared, all is fine. Otherwise, we sleep for a bit and try again. In
> the worst case we sleep for an extra second waiting for the mutex to be
> released (no one touching the GPU is allowed the struct_mutex whilst the
> I915_RESET_IN_PROGRESS bit is set). But when we have a direct reset,
> this allows us to clean up the reset worker faster.
>
> v2: Remember to call wake_up_bit() after changing (for the faster wakeup
> as promised)
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 ++++--
> drivers/gpu/drm/i915/i915_irq.c | 30 ++++++++++++++++++------------
> 2 files changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ff4173e6e298..c1b890dbd6cc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1798,11 +1798,13 @@ int i915_reset(struct drm_i915_private *dev_priv)
> intel_sanitize_gt_powersave(dev_priv);
> intel_autoenable_gt_powersave(dev_priv);
>
> - return 0;
> +out:
> + wake_up_bit(&error->flags, I915_RESET_IN_PROGRESS);
> + return ret;
>
> error:
> set_bit(I915_WEDGED, &error->flags);
> - return ret;
> + goto out;
After initial surprice, and surprices are negative,
this is short, keeps the error stuff out from bulkcode
and keeps wakeup neatly in both paths.
To reduce the surprice effect, label could be wakeup_out.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
> }
>
> static int i915_pm_suspend(struct device *kdev)
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 2c7cb5041511..699ee2c7a3e4 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2497,7 +2497,7 @@ static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv)
> char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
> char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
> char *reset_done_event[] = { I915_ERROR_UEVENT "=0", NULL };
> - int ret;
> + int ret = -EAGAIN;
>
> kobject_uevent_env(kobj, KOBJ_CHANGE, error_event);
>
> @@ -2512,21 +2512,27 @@ static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv)
> * simulated reset via debugs, so get an RPM reference.
> */
> intel_runtime_pm_get(dev_priv);
> -
> intel_prepare_reset(dev_priv);
>
> - /*
> - * All state reset _must_ be completed before we update the
> - * reset counter, for otherwise waiters might miss the reset
> - * pending state and not properly drop locks, resulting in
> - * deadlocks with the reset work.
> - */
> - mutex_lock(&dev_priv->drm.struct_mutex);
> - ret = i915_reset(dev_priv);
> - mutex_unlock(&dev_priv->drm.struct_mutex);
> + do {
> + /*
> + * All state reset _must_ be completed before we update the
> + * reset counter, for otherwise waiters might miss the reset
> + * pending state and not properly drop locks, resulting in
> + * deadlocks with the reset work.
> + */
> + if (mutex_trylock(&dev_priv->drm.struct_mutex)) {
> + ret = i915_reset(dev_priv);
> + mutex_unlock(&dev_priv->drm.struct_mutex);
> + }
>
> - intel_finish_reset(dev_priv);
> + /* We need to wait for anyone holding the lock to wakeup */
> + } while (wait_on_bit_timeout(&dev_priv->gpu_error.flags,
> + I915_RESET_IN_PROGRESS,
> + TASK_UNINTERRUPTIBLE,
> + HZ));
>
> + intel_finish_reset(dev_priv);
> intel_runtime_pm_put(dev_priv);
>
> if (ret == 0)
> --
> 2.9.3
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-09-08 10:53 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-05 13:04 Non-blocking, explict fences Chris Wilson
2016-09-05 13:04 ` [PATCH 01/21] drm/i915: Add a sw fence for collecting up dma fences Chris Wilson
2016-09-05 13:04 ` [PATCH 02/21] drm/i915: Only queue requests during execlists submission Chris Wilson
2016-09-05 13:04 ` [PATCH 03/21] drm/i915: Record the position of the workarounds in the tail of the request Chris Wilson
2016-09-05 13:04 ` [PATCH 04/21] drm/i915: Compute the ELSP register location once Chris Wilson
2016-09-05 13:04 ` [PATCH 05/21] drm/i915: Reorder submitting the requests to ELSP Chris Wilson
2016-09-05 13:04 ` [PATCH 06/21] drm/i915: Simplify ELSP queue request tracking Chris Wilson
2016-09-05 13:04 ` [PATCH 07/21] drm/i915: Separate out reset flags from the reset counter Chris Wilson
2016-09-05 13:04 ` [PATCH 08/21] drm/i915: Drop local struct_mutex around intel_init_emon[ilk] Chris Wilson
2016-09-05 13:04 ` [PATCH 09/21] drm/i915: Expand bool interruptible to pass flags to i915_wait_request() Chris Wilson
2016-09-05 13:04 ` [PATCH 10/21] drm/i915: Mark up all locked waiters Chris Wilson
2016-09-06 9:24 ` Mika Kuoppala
2016-09-05 13:04 ` [PATCH 11/21] drm/i915: Perform a direct reset of the GPU from the waiter Chris Wilson
2016-09-05 13:04 ` [PATCH 12/21] drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker Chris Wilson
2016-09-06 9:28 ` Mika Kuoppala
2016-09-05 13:04 ` [PATCH 13/21] drm/i915: Update reset path to fix incomplete requests Chris Wilson
2016-09-05 13:04 ` [PATCH 14/21] drm/i915: Drive request submission through fence callbacks Chris Wilson
2016-09-05 13:04 ` [PATCH 15/21] drm/i915: Reorder i915_add_request to separate the phases better Chris Wilson
2016-09-06 9:36 ` Mika Kuoppala
2016-09-05 13:04 ` [PATCH 16/21] drm/i915: Prepare object synchronisation for asynchronicity Chris Wilson
2016-09-05 13:04 ` [PATCH 17/21] drm/i915/guc: Prepare for nonblocking execbuf submission Chris Wilson
2016-09-05 13:04 ` [PATCH 18/21] drm/i915: Nonblocking request submission Chris Wilson
2016-09-05 13:04 ` [PATCH 19/21] drm/i915: Serialise execbuf operation after a dma-buf reservation object Chris Wilson
2016-09-05 13:04 ` [PATCH 20/21] drm/i915: Enable userspace to opt-out of implicit fencing Chris Wilson
2016-09-05 13:04 ` [PATCH 21/21] drm/i915: Support explicit fencing for execbuf Chris Wilson
2016-09-05 13:59 ` ✗ Fi.CI.BAT: failure for series starting with [01/21] drm/i915: Add a sw fence for collecting up dma fences Patchwork
2016-09-05 14:07 ` Chris Wilson
2016-09-07 14:44 ` [PATCH v2 01/22] " Chris Wilson
2016-09-07 14:44 ` [PATCH v2 02/22] drm/i915: Only queue requests during execlists submission Chris Wilson
2016-09-07 14:44 ` [PATCH v2 03/22] drm/i915: Record the position of the workarounds in the tail of the request Chris Wilson
2016-09-07 14:44 ` [PATCH v2 04/22] drm/i915: Compute the ELSP register location once Chris Wilson
2016-09-07 14:44 ` [PATCH v2 05/22] drm/i915: Reorder submitting the requests to ELSP Chris Wilson
2016-09-07 14:45 ` [PATCH v2 06/22] drm/i915: Simplify ELSP queue request tracking Chris Wilson
2016-09-07 14:45 ` [PATCH v2 07/22] drm/i915: Separate out reset flags from the reset counter Chris Wilson
2016-09-07 14:45 ` [PATCH v2 08/22] drm/i915: Drop local struct_mutex around intel_init_emon[ilk] Chris Wilson
2016-09-07 14:45 ` [PATCH v2 09/22] drm/i915: Expand bool interruptible to pass flags to i915_wait_request() Chris Wilson
2016-09-07 14:45 ` [PATCH v2 10/22] drm/i915: Mark up all locked waiters Chris Wilson
2016-09-07 14:45 ` [PATCH v2 11/22] drm/i915: Perform a direct reset of the GPU from the waiter Chris Wilson
2016-09-08 9:35 ` Mika Kuoppala
2016-09-07 14:45 ` [PATCH v2 12/22] drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker Chris Wilson
2016-09-08 10:52 ` Mika Kuoppala [this message]
2016-09-08 13:24 ` Chris Wilson
2016-09-07 14:45 ` [PATCH v2 13/22] drm/i915: Update reset path to fix incomplete requests Chris Wilson
2016-09-08 12:03 ` Mika Kuoppala
2016-10-03 12:44 ` Tvrtko Ursulin
2016-10-03 12:56 ` Chris Wilson
2016-09-07 14:45 ` [PATCH v2 14/22] drm/i915: Drive request submission through fence callbacks Chris Wilson
2016-09-07 14:45 ` [PATCH v2 15/22] drm/i915: Reorder i915_add_request to separate the phases better Chris Wilson
2016-09-07 14:45 ` [PATCH v2 16/22] drm/i915: Prepare object synchronisation for asynchronicity Chris Wilson
2016-09-07 14:45 ` [PATCH v2 17/22] drm/i915/guc: Prepare for nonblocking execbuf submission Chris Wilson
2016-09-12 14:14 ` Tvrtko Ursulin
2016-09-07 14:45 ` [PATCH v2 18/22] drm/i915: Ignore valid but unknown semaphores Chris Wilson
2016-09-08 6:31 ` Joonas Lahtinen
2016-09-07 14:45 ` [PATCH v2 19/22] drm/i915: Nonblocking request submission Chris Wilson
2016-09-07 14:45 ` [PATCH v2 20/22] drm/i915: Serialise execbuf operation after a dma-buf reservation object Chris Wilson
2016-09-07 14:45 ` [PATCH v2 21/22] drm/i915: Enable userspace to opt-out of implicit fencing Chris Wilson
2016-09-07 14:45 ` [PATCH v2 22/22] drm/i915: Support explicit fencing for execbuf Chris Wilson
2016-09-07 15:49 ` ✗ Fi.CI.BAT: warning for series starting with [01/21] drm/i915: Add a sw fence for collecting up dma fences (rev22) 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=87zini7jfe.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.