Re: [PATCH] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
Date: Tue, 10 Apr 2018 11:34:13 +0100	[thread overview]
Message-ID: <152335645321.3167.10340594219741431631@mail.alporthouse.com> (raw)
In-Reply-To: <7a7a4c0b-1270-982b-6e69-96ffd2257a73@linux.intel.com>

Quoting Tvrtko Ursulin (2018-04-10 11:22:55)
> 
> On 10/04/2018 10:57, Chris Wilson wrote:
> > But I'm not understanding the failure -- why is the estimate bad? At the
> > very least we still ensure that it is monotonic? Is it just the jitter
> > you are worrying about? (If the estimate is bad here, isn't it always
> > bad?)
> 
> As far as I have seen failures from CI are all estimate being too large. 
> (no jitter and no going backwards)
> 
> What I suspect is going bad in either case, is that we must not add the 
> delta from current jiffies to internal runtime pm counters if state is 
> not suspended. If we do that we are accounting an unknown period of time 
> as suspended time and that would explain the over-estimation.
> 
> In other words we are only allowed to estimate if the current state is 
> definitely suspended. If it is anything else we need to report either 
> the last estimated value, or the last real value, depending what is more 
> recent.

i.e. we must not use kdev->power.suspended_jiffies before we know it is
set.

Ok, that is stating to make sense. Thanks, can you update the commitmsg
with this (pretty much verbatim as it is a good explanation).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx