[Intel-gfx] [PATCH] drm/i915: add turbo boost trace point

[Ville Syrjälä]

On Wed, Nov 19, 2014 at 08:29:50AM -0800, Jesse Barnes wrote:
> On Wed, 19 Nov 2014 17:19:23 +0100
> Daniel Vetter <daniel at ffwll.ch> wrote:
> 
> > On Wed, Nov 19, 2014 at 07:39:17AM -0800, Jesse Barnes wrote:
> > > On Wed, 19 Nov 2014 15:00:04 +0100
> > > Daniel Vetter <daniel at ffwll.ch> wrote:
> > > 
> > > > On Tue, Nov 18, 2014 at 01:12:29PM -0800, Jesse Barnes wrote:
> > > > > Might be helpful for debugging places where userspace ends up boosting
> > > > > or waiting where it doesn't intend to.
> > > > 
> > > > Might be feels a bit weak justification for a new tracepoint imo. Please
> > > > drum up more support.
> > > 
> > > I put it together for some media playback debugging we're doing on
> > > Chrome, where I suspect we're boosting when we don't want to (possibly
> > > due to userspace waits).
> > 
> > Hm, I've discussed this exact topic many moons ago with vpg folks and
> > they've said that the boosting done for media workloads on the idle->busy
> > transition annoys them. Iirc the plan we've hashed out was to add an
> > execbuf flag to prevent the execbuf boosting.
> > 
> > We've also discussed the wait boosting but that's imo just a bug in libva
> > ;-) And for debugging pointless waits we already have good tracepoints
> > imo.
> 
> We have tracing for waits, but my expectation was that we may end up
> growing or adding new boost points elsewhere, so having an explicit
> trace would make sense anyway.
> 
> But we've already typed many more lines about this than the patch
> itself contains, so feel free to drop/ignore.  It's easy enough to add
> on an ad-hoc basis.

Or just use the function tracer. And combine with the already existing rps
event in case you want the freq too.

-- 
Ville Syrjälä
Intel OTC