From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Eero Tamminen <eero.t.tamminen@intel.com>,
"Rantala, Valtteri" <valtteri.rantala@intel.com>
Subject: Re: [PATCH v4] drm/i915: Optimistically spin for the request completion
Date: Fri, 20 Mar 2015 16:01:52 +0000 [thread overview]
Message-ID: <550C4470.8070506@linux.intel.com> (raw)
In-Reply-To: <1426862206-14441-1-git-send-email-chris@chris-wilson.co.uk>
On 03/20/2015 02:36 PM, Chris Wilson wrote:
> This provides a nice boost to mesa in swap bound scenarios (as mesa
> throttles itself to the previous frame and given the scenario that will
> complete shortly). It will also provide a good boost to systems running
> with semaphores disabled and so frequently waiting on the GPU as it
> switches rings. In the most favourable of microbenchmarks, this can
> increase performance by around 15% - though in practice improvements
> will be marginal and rarely noticeable.
>
> v2: Account for user timeouts
> v3: Limit the spinning to a single jiffie (~1us) at most. On an
> otherwise idle system, there is no scheduler contention and so without a
> limit we would spin until the GPU is ready.
> v4: Drop forcewake - the lazy coherent access doesn't require it, and we
> have no reason to believe that the forcewake itself improves seqno
> coherency - it only adds delay.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Cc: Eero Tamminen <eero.t.tamminen@intel.com>
> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Still against a toggle switch like a simple module parameter?
> ---
> drivers/gpu/drm/i915/i915_gem.c | 44 +++++++++++++++++++++++++++++++++++------
> 1 file changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 2e17a254aac1..9988e65c1440 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1181,6 +1181,29 @@ static bool missed_irq(struct drm_i915_private *dev_priv,
> return test_bit(ring->id, &dev_priv->gpu_error.missed_irq_rings);
> }
>
> +static int __i915_spin_request(struct drm_i915_gem_request *rq)
> +{
> + unsigned long timeout;
> +
> + if (i915_gem_request_get_ring(rq)->irq_refcount)
> + return -EBUSY;
So if someone else is already waiting on this ring skip the spin and do
the sleep-wait.
That would mean earlier waiter didn't manage to spin to completion so
for subsequent ones does it make sense to try to spin? If we assume
waiters are arriving here in submission order then no, they should
proceed to sleep-wait. But if waiters are arriving here in random order,
and that is purely up to userspace I think, then I am not sure?
On the other hand if we allowed this "out-of-order waiters" that would
potentially be too much spinning so maybe it is better like it is.
> + timeout = jiffies + 1;
> + while (!need_resched()) {
> + if (i915_gem_request_completed(rq, true))
> + return 0;
> +
> + if (time_after_eq(jiffies, timeout))
> + break;
> +
> + cpu_relax_lowlatency();
> + }
> + if (i915_gem_request_completed(rq, false))
> + return 0;
> +
> + return -EAGAIN;
> +}
> +
> /**
> * __i915_wait_request - wait until execution of request has finished
> * @req: duh!
> @@ -1225,12 +1248,20 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
> if (ring->id == RCS && INTEL_INFO(dev)->gen >= 6)
> gen6_rps_boost(dev_priv, file_priv);
>
> - if (!irq_test_in_progress && WARN_ON(!ring->irq_get(ring)))
> - return -ENODEV;
> -
> /* Record current time in case interrupted by signal, or wedged */
> trace_i915_gem_request_wait_begin(req);
> before = ktime_get_raw_ns();
> +
> + /* Optimistic spin for the next jiffie before touching IRQs */
> + ret = __i915_spin_request(req);
> + if (ret == 0)
> + goto out;
> +
> + if (!irq_test_in_progress && WARN_ON(!ring->irq_get(ring))) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> for (;;) {
> struct timer_list timer;
>
> @@ -1279,14 +1310,15 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
> destroy_timer_on_stack(&timer);
> }
> }
> - now = ktime_get_raw_ns();
> - trace_i915_gem_request_wait_end(req);
> -
> if (!irq_test_in_progress)
> ring->irq_put(ring);
>
> finish_wait(&ring->irq_queue, &wait);
>
> +out:
> + now = ktime_get_raw_ns();
> + trace_i915_gem_request_wait_end(req);
> +
> if (timeout) {
> s64 tres = *timeout - (now - before);
>
>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-03-20 16:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 15:29 [PATCH v2] drm/i915: Optimistically spin for the request completion Chris Wilson
2015-03-11 21:18 ` Chris Wilson
2015-03-12 9:07 ` Chris Wilson
2015-03-12 9:17 ` Daniel Vetter
2015-03-12 11:11 ` [PATCH v3] " Chris Wilson
2015-03-12 12:06 ` Chris Wilson
2015-03-12 13:14 ` Tvrtko Ursulin
2015-03-12 13:18 ` Chris Wilson
2015-03-12 15:18 ` Tvrtko Ursulin
2015-03-12 16:28 ` Chris Wilson
2015-03-12 16:41 ` Tvrtko Ursulin
2015-03-12 16:50 ` Chris Wilson
2015-03-12 17:32 ` Tvrtko Ursulin
2015-03-13 9:33 ` Daniel Vetter
2015-03-12 19:27 ` shuang.he
2015-03-19 15:16 ` Chris Wilson
2015-03-20 14:54 ` Daniel Vetter
2015-03-20 15:27 ` Chris Wilson
2015-03-20 14:36 ` [PATCH v4] " Chris Wilson
2015-03-20 16:01 ` Tvrtko Ursulin [this message]
2015-03-20 16:19 ` Chris Wilson
2015-03-20 16:31 ` Tvrtko Ursulin
2015-03-23 8:29 ` Daniel Vetter
2015-03-20 22:59 ` Chris Wilson
2015-03-21 9:49 ` Chris Wilson
2015-03-23 8:31 ` Daniel Vetter
2015-03-23 9:09 ` Chris Wilson
2015-03-20 21:30 ` shuang.he
2015-03-11 23:07 ` [PATCH v2] " shuang.he
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=550C4470.8070506@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=eero.t.tamminen@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=valtteri.rantala@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