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@xxxxxxxx> 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@xxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
