Re: [PATCH 14/19] drm/i915: Reconstruct active state on starting busy-stats

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 14/19] drm/i915: Reconstruct active state on starting busy-stats
Date: Mon, 08 Jan 2018 14:29:37 +0000	[thread overview]
Message-ID: <151542177747.23681.1369311180729413382@mail.alporthouse.com> (raw)
In-Reply-To: <16d9bdf1-e74d-c760-0547-5c2e8ee88603@linux.intel.com>

Quoting Tvrtko Ursulin (2018-01-08 14:18:53)
> 
> On 02/01/2018 15:12, Chris Wilson wrote:
> > We have a hole in our busy-stat accounting if the pmu is enabled during
> > a long running batch, the pmu will not start accumulating busy-time
> > until the next context switch. This then fails tests that are only
> > sampling a single batch.
> 
> Oops, something in recent perf_pmu rework uncovered this?

Yeah, the tweaks reduced some tests to submitting a single batch started
before the counters. Previously all tests started the counters then
submitted the workload. I had a test planned, obviously forgot to write
it. I couldn't think of a way to guarantee hitting the lite-restore case
thought.

> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > ---
> >   drivers/gpu/drm/i915/intel_engine_cs.c | 9 ++++++++-
> >   1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index ebdcbcbacb3c..c2f01ff96ce1 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -1946,8 +1946,15 @@ int intel_enable_engine_stats(struct intel_engine_cs *engine)
> >       spin_lock_irqsave(&engine->stats.lock, flags);
> >       if (engine->stats.enabled == ~0)
> >               goto busy;
> > -     if (engine->stats.enabled++ == 0)
> > +     if (engine->stats.enabled++ == 0) {
> >               engine->stats.enabled_at = ktime_get();
> > +
> > +             /* XXX submission method oblivious */
> 
> You mean once busy stats support for the GuC gets added?

I was just thinking that we shouldn't be poking into execlists here and
that we need an agnostic method for execlists to tell busy_stats that it
is starting active. Or something.

> > +             engine->stats.active = port_count(&engine->execlists.port[1]);
> > +             engine->stats.active += port_count(&engine->execlists.port[0]);
> 
> Hm, wouldn't this have the potential to over-account the active counter 
> resulting in permanent 100%? Port count is [0, 2], where 2 is 
> re-submission of port 0, while engine->stats.active is [0, 2], where 
> this 2 is number of ports. In other words I think the correct method 
> would be:
> 
> if (port_count(0))
>         active++;
> if (port_count(1))
>         active++;

I thought we needed for stats.active to reflect the number of pending
context_out we will report. So for the lite-restore case, I thought 2
was the correct value.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx