From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 7/7] drm/i915: Mark the GT as busy before idling the previous request
Date: Thu, 17 Aug 2017 16:38:00 +0300 [thread overview]
Message-ID: <1502977080.31411.3.camel@linux.intel.com> (raw)
In-Reply-To: <20170816085210.4199-7-chris@chris-wilson.co.uk>
On Wed, 2017-08-16 at 09:52 +0100, Chris Wilson wrote:
> In a synchronous setup, we may retire the last request before we
> complete allocating the next request. As the last request is retired, we
> queue a timer to mark the device as idle, and promptly have to execute
> ad cancel that timer once we complete allocating the request and need to
> keep the device awake. If we rearrange the mark_busy() to occur before
> we retire the previous request, we can skip this ping-pong.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
<SNIP>
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -265,6 +265,13 @@ static int reserve_seqno(struct intel_engine_cs *engine)
>
> static void unreserve_seqno(struct intel_engine_cs *engine)
> {
> + if (!--engine->i915->gt.active_requests) {
> + GEM_BUG_ON(!engine->i915->gt.awake);
> + mod_delayed_work(engine->i915->wq,
> + &engine->i915->gt.idle_work,
> + msecs_to_jiffies(100));
> + }
This function could use a better name, now it seems to tightly tie to
seqno only, and idle work is very unexpected. How about just
unreserve_engine vs. reserve_engine?
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:[~2017-08-17 13:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 8:52 [PATCH 1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs Chris Wilson
2017-08-16 8:52 ` [PATCH 2/7] drm/i915: Check context status before looking up our obj/vma Chris Wilson
2017-08-17 14:10 ` Mika Kuoppala
2017-08-17 15:43 ` Chris Wilson
2017-08-16 8:52 ` [PATCH 3/7] drm/i915: Convert execbuf to use struct-of-array packing for critical fields Chris Wilson
2017-08-16 8:52 ` [PATCH 4/7] drm/i915: Simplify eb_lookup_vmas() Chris Wilson
2017-08-16 8:52 ` [PATCH 5/7] drm/i915: Replace execbuf vma ht with an idr Chris Wilson
2017-08-16 8:52 ` [PATCH 6/7] drm/i915: Trivial grammar fix s/opt of/opt out of/ in comment Chris Wilson
2017-08-17 13:38 ` Joonas Lahtinen
2017-08-16 8:52 ` [PATCH 7/7] drm/i915: Mark the GT as busy before idling the previous request Chris Wilson
2017-08-17 13:38 ` Joonas Lahtinen [this message]
2017-08-17 14:47 ` [PATCH v2] " Chris Wilson
2017-08-18 9:11 ` Joonas Lahtinen
2017-08-16 9:10 ` ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs Patchwork
2017-08-17 15:36 ` ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs (rev2) Patchwork
2017-08-18 11:40 ` Chris Wilson
2017-08-18 11:07 ` [PATCH 1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs Mika Kuoppala
2017-08-18 11:17 ` Chris Wilson
2017-08-18 11:23 ` Mika Kuoppala
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=1502977080.31411.3.camel@linux.intel.com \
--to=joonas.lahtinen@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.