From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: mika.kuoppala@intel.com
Subject: Re: [PATCH 01/17] drm/i915: Add a sw fence for collecting up dma fences
Date: Mon, 29 Aug 2016 16:43:04 +0300 [thread overview]
Message-ID: <1472478184.3943.16.camel@linux.intel.com> (raw)
In-Reply-To: <20160828204624.21193-2-chris@chris-wilson.co.uk>
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> +static void i915_sw_fence_free(struct kref *kref)
> +{
> + struct i915_sw_fence *fence = container_of(kref, typeof(*fence), kref);
> +
> + WARN_ON(atomic_read(&fence->pending) > 0);
> +
> + if (fence->flags & I915_SW_FENCE_MASK)
> + WARN_ON(__i915_sw_fence_notify(fence) != NOTIFY_DONE);
Suspicious to call _notify from free without any notification type
parameter. Better add the notification type parameter.
> +static void __i915_sw_fence_wake_up_all(struct i915_sw_fence *fence,
> + struct list_head *continuation)
> +{
> + wait_queue_head_t *x = &fence->wait;
Rather mystique variable naming to me.
> + unsigned long flags;
> +
> + atomic_set(&fence->pending, -1); /* 0 -> -1 [done] */
> +
> + /*
> + * To prevent unbounded recursion as we traverse the graph of
> + * i915_sw_fences, we move the task_list from this the next ready
> + * fence to the tail of the original fence's task_list
".. from this the next ready fence to ..." Strange expression.
> + * (and so added to the list to be woken).
> + */
> +
> + smp_mb__before_spinlock();
> + spin_lock_irqsave_nested(&x->lock, flags, 1 + !!continuation);
> + if (continuation) {
> + list_splice_tail_init(&x->task_list, continuation);
> + } else {
> + LIST_HEAD(extra);
> +
> + do {
> + __wake_up_locked_key(x, TASK_NORMAL, &extra);
It might be worth mentioning here that we've rigged our callback so
that it will be called synchronously here so that the code can be
understood with less waitqueue internal digging.
> +
> + if (list_empty(&extra))
> + break;
> +
> + list_splice_tail_init(&extra, &x->task_list);
> + } while (1);
Why exactly do you loop here, shouldn't single invocation of
__wake_up_locked_key trigger all the callbacks and result in all the
entries being listed?
> +void i915_sw_fence_init(struct i915_sw_fence *fence, i915_sw_fence_notify_t fn)
> +{
> + BUG_ON((unsigned long)fn & ~I915_SW_FENCE_MASK);
> +
> + init_waitqueue_head(&fence->wait);
> + kref_init(&fence->kref);
> + atomic_set(&fence->pending, 1);
fence->pending = ATOMIC_INIT(1);
> +static bool i915_sw_fence_check_if_after(struct i915_sw_fence *fence,
> + const struct i915_sw_fence * const signaler)
Naming is still bad, but _err_if_after is not much better.
With above addressed;
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-08-29 13:43 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-28 20:46 Explicit fencing + nonblocking execbuf Chris Wilson
2016-08-28 20:46 ` [PATCH 01/17] drm/i915: Add a sw fence for collecting up dma fences Chris Wilson
2016-08-29 13:43 ` Joonas Lahtinen [this message]
2016-08-29 15:45 ` Chris Wilson
2016-08-30 7:42 ` Joonas Lahtinen
2016-08-28 20:46 ` [PATCH 02/17] drm/i915: Only queue requests during execlists submission Chris Wilson
2016-08-28 20:46 ` [PATCH 03/17] drm/i915: Record the position of the workarounds in the tail of the request Chris Wilson
2016-08-28 20:46 ` [PATCH 04/17] drm/i915: Compute the ELSP register location once Chris Wilson
2016-08-28 20:46 ` [PATCH 05/17] drm/i915: Reorder submitting the requests to ELSP Chris Wilson
2016-08-28 20:46 ` [PATCH 06/17] drm/i915: Simplify ELSP queue request tracking Chris Wilson
2016-08-29 12:31 ` Mika Kuoppala
2016-08-28 20:46 ` [PATCH 07/17] drm/i915: Separate out reset flags from the reset counter Chris Wilson
2016-08-30 14:23 ` [PATCH v2] " Chris Wilson
2016-08-30 14:40 ` Mika Kuoppala
2016-08-28 20:46 ` [PATCH 08/17] drm/i915: Drop local struct_mutex around intel_init_emon[ilk] Chris Wilson
2016-08-29 13:53 ` Mika Kuoppala
2016-08-29 13:57 ` Joonas Lahtinen
2016-08-28 20:46 ` [PATCH 09/17] drm/i915: Expand bool interruptible to pass flags to i915_wait_request() Chris Wilson
2016-08-29 14:00 ` Joonas Lahtinen
2016-08-28 20:46 ` [PATCH 10/17] drm/i915: Perform a direct reset of the GPU from the waiter Chris Wilson
2016-08-28 20:46 ` [PATCH 11/17] drm/i915: Update reset path to fix incomplete requests Chris Wilson
2016-08-28 20:46 ` [PATCH 12/17] drm/i915: Drive request submission through fence callbacks Chris Wilson
2016-08-30 8:07 ` Joonas Lahtinen
2016-08-28 20:46 ` [PATCH 13/17] drm/i915: Move execbuf object synchronisation to i915_gem_execbuffer Chris Wilson
2016-08-30 8:10 ` Joonas Lahtinen
2016-08-30 9:22 ` Chris Wilson
2016-08-28 20:46 ` [PATCH 14/17] drm/i915: Nonblocking request submission Chris Wilson
2016-08-30 8:35 ` Joonas Lahtinen
2016-08-30 8:43 ` Chris Wilson
2016-08-30 8:49 ` Joonas Lahtinen
2016-08-30 11:18 ` [PATCH v2] " Chris Wilson
2016-08-31 8:36 ` Joonas Lahtinen
2016-08-28 20:46 ` [PATCH 15/17] drm/i915: Serialise execbuf operation after a dma-buf reservation object Chris Wilson
2016-08-30 8:37 ` Joonas Lahtinen
2016-08-28 20:46 ` [PATCH 16/17] drm/i915: Enable userspace to opt-out of implicit fencing Chris Wilson
2016-08-30 8:45 ` Joonas Lahtinen
2016-08-30 9:00 ` Chris Wilson
2016-08-28 20:46 ` [PATCH 17/17] drm/i915: Support explicit fencing for execbuf Chris Wilson
2016-08-29 8:55 ` Chris Wilson
2016-08-30 9:42 ` Joonas Lahtinen
2016-08-28 21:18 ` ✓ Fi.CI.BAT: success for series starting with [01/17] drm/i915: Add a sw fence for collecting up dma fences Patchwork
2016-08-30 11:50 ` ✓ Fi.CI.BAT: success for series starting with [01/17] drm/i915: Add a sw fence for collecting up dma fences (rev2) Patchwork
2016-08-30 14:50 ` ✓ Fi.CI.BAT: success for series starting with [01/17] drm/i915: Add a sw fence for collecting up dma fences (rev3) 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=1472478184.3943.16.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--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 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.