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

[Chris Wilson]

Quoting Tvrtko Ursulin (2020-02-07 16:49:17)
> 
> On 07/02/2020 16:33, Chris Wilson wrote:
> > 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?
> 
> Yes, it's in the cover letter - we must not have disappearing 
> contributions - client can submit from one context for a bit, close it, 
> and oops usage history lost.

If only we had a mechanism for accumulating contributions from stale
engines and then from stale contests?
 
> ce->drm_client? :)

Yeah that is equally icky for swimming upstream.

Ok, I have an idea for capturing the contributions at close rather than
having to do global accumulations at runtime.
-Chris