From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Ankit Navik <ankit.p.navik@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v4 1/3] drm/i915: Get active pending request for given context
Date: Thu, 14 Mar 2019 10:39:07 +0000 [thread overview]
Message-ID: <8cd6fd96-8faf-b6d5-a590-4b4ba6881580@linux.intel.com> (raw)
In-Reply-To: <1552552615-6703-2-git-send-email-ankit.p.navik@intel.com>
On 14/03/2019 08:36, Ankit Navik wrote:
> From: Praveen Diwakar <praveen.diwakar@intel.com>
>
> This patch gives us the active pending request count which is yet
> to be submitted to the GPU
>
> V2:
> * Change 64-bit to atomic for request count. (Tvrtko Ursulin)
>
> V3:
> * Remove mutex for request count.
> * Rebase.
> * Fixes hitting underflow for predictive request. (Tvrtko Ursulin)
>
> V4:
> * Rebase.
>
> Cc: Aravindan Muthukumar <aravindan.muthukumar@intel.com>
> Cc: Kedar J Karanje <kedar.j.karanje@intel.com>
> Cc: Yogesh Marathe <yogesh.marathe@intel.com>
> Signed-off-by: Praveen Diwakar <praveen.diwakar@intel.com>
> Signed-off-by: Ankit Navik <ankit.p.navik@intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 1 +
> drivers/gpu/drm/i915/i915_gem_context.h | 5 +++++
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++
> drivers/gpu/drm/i915/intel_lrc.c | 3 +++
> 4 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
> index 280813a..a5876fe 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -453,6 +453,7 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
> }
>
> trace_i915_context_create(ctx);
> + atomic_set(&ctx->req_cnt, 0);
>
> return ctx;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.h b/drivers/gpu/drm/i915/i915_gem_context.h
> index ca150a7..c940168 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> @@ -227,6 +227,11 @@ struct i915_gem_context {
> * context close.
> */
> struct list_head handles_list;
> +
> + /** req_cnt: tracks the pending commands, based on which we decide to
> + * go for low/medium/high load configuration of the GPU.
> + */
> + atomic_t req_cnt;
> };
>
> static inline bool i915_gem_context_is_closed(const struct i915_gem_context *ctx)
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 02adcaf..a38963b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -2475,6 +2475,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> */
> eb.request->batch = eb.batch;
>
> + atomic_inc(&eb.ctx->req_cnt);
> +
> trace_i915_request_queue(eb.request, eb.batch_flags);
> err = eb_submit(&eb);
> err_request:
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 34a0866..d0af37d 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -780,6 +780,9 @@ static void execlists_dequeue(struct intel_engine_cs *engine)
>
> last = rq;
> submit = true;
> +
> + if (atomic_read(&rq->gem_context->req_cnt) > 0)
> + atomic_dec(&rq->gem_context->req_cnt);
Every review round I keep pointing out this is wrong and you keep
persisting to have it like this. :( Would you in my place want to keep
reviewing in these circumstances?
As Chris also pointed out it is not atomic so in theory doesn't even
protect against underflow and I repeat, yet again, is a hint the
placement is unbalanced.
I pointed you to some of my old patches which do correct accounting of
per engine queued / runnable / running, to give an idea where to put the
inc/dec.
Chris now also suggests maybe to tie it with timelines (AFAIU), so you
could also see where requests are added and removed from the
ce->ring->timeline list.
You say you tried something with my patches but "didnt see much
power benefit with that" - what exactly have you tried? And what is not
much?
I am still curious what metric works for this. The one you implement is
something like queued + _sometimes_ runnable. Sometimes because you may
or may not be decrementing runnable depending on ELSP contention. And
number of ELSP slots may change with GuC and/or Gen11 so I worry it is
way to undefined even ignoring the underflow issue.
Regards,
Tvrtko
> }
>
> rb_erase_cached(&p->node, &execlists->queue);
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-03-14 10:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-14 8:36 [PATCH v4 0/3] drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel Ankit Navik
2019-03-14 8:36 ` [PATCH v4 1/3] drm/i915: Get active pending request for given context Ankit Navik
2019-03-14 8:55 ` Chris Wilson
2019-03-14 10:39 ` Tvrtko Ursulin [this message]
2019-03-14 8:36 ` [PATCH v4 2/3] drm/i915: set optimum eu/slice/sub-slice configuration based on load type Ankit Navik
2019-03-14 10:45 ` Tvrtko Ursulin
2019-03-14 10:52 ` kbuild test robot
2019-03-14 11:04 ` kbuild test robot
2019-03-14 15:50 ` kbuild test robot
2019-03-14 8:36 ` [PATCH v4 3/3] drm/i915: Predictive governor to control eu/slice/subslice Ankit Navik
2019-03-14 10:58 ` Tvrtko Ursulin
2019-03-14 9:35 ` ✗ Fi.CI.BAT: failure for drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel 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=8cd6fd96-8faf-b6d5-a590-4b4ba6881580@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=ankit.p.navik@intel.com \
--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.