Re: [Intel-gfx] [PATCH 5/6] drm/i915: Track per drm client engine class busyness

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Intel-gfx@lists.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Track per drm client engine class busyness
Date: Fri, 07 Feb 2020 16:33:34 +0000	[thread overview]
Message-ID: <158109321467.16098.12817907526709789256@skylake-alporthouse-com> (raw)
In-Reply-To: <20200207161331.23447-6-tvrtko.ursulin@linux.intel.com>

Quoting Tvrtko Ursulin (2020-02-07 16:13:30)
>  static inline void
> -__intel_context_stats_start(struct intel_context *ce, ktime_t now)
> +__intel_context_stats_start(struct intel_context *ce,
> +                           struct intel_engine_cs *engine,
> +                           ktime_t now)
>  {
>         struct intel_context_stats *stats = &ce->stats;
> -
> -       if (!stats->active) {
> -               stats->start = now;
> -               stats->active = true;
> +       struct i915_gem_context *ctx;
> +
> +       if (stats->active)
> +               return;
> +
> +       stats->start = now;
> +       stats->active = true;
> +
> +       rcu_read_lock();
> +       ctx = rcu_dereference(ce->gem_context);
> +       if (ctx && ctx->client) {

I'd rather avoid having to dig into the GEM context down here next to
the HW.

First thought would be to keep the stats local on the intel_context and
for the client to chase collate them when the user reads the fd.

Hmm, didn't you structure it like so earlier? What made you change your
mind?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx