On Sat, Sep 1, 2012 at 8:35 PM, Ben Widawsky <ben at bwidawsk.net> wrote: > On 2012-09-01 11:28, Arjan van de Ven wrote: >> >> On 9/1/2012 11:26 AM, Ben Widawsky wrote: >>> >>> On 2012-08-30 04:26, Daniel Vetter wrote: >>>> >>>> We've had and still have too many issues where the gpu turbot doesn't >>>> quite to what it's supposed to do (or what we want it to do). >>>> >>>> Adding a tracepoint to track when the desired gpu frequence changes >>>> should help a lot in characterizing and understanding problematic >>>> workloads. >>>> >>>> Also, this should be fairly interesting for power tuning (and >>>> especially noticing when the gpu is stuck in high frequencies, as has >>>> happened in the past) and hence for integration into powertop and >>>> similar tools. >>>> >>>> Cc: Arjan van de Ven <arjan at linux.intel.com> >>>> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> >>> >>> >>> I can't help but think it's equally interesting to know when the queue >>> the work as well. >>> >>> >> >> btw... if the userspace interface (e.g. the actual event) is not >> controversial and very unlikely to change, >> I'd like to start coding the powertop support for this already.... > > > I have no problem with Daniel's patch. It's just a matter of cutting through > some scheduler BS of "when the GPU wants to change frequency" vs. "when we > actually change the GPU frequency." I think *both* are interesting. Hm, aren't there some neat tracepoints to measure the latency of work items around already? I agree that this might be useful, but just adding a tracepoint for this one workqueue item feels like overkill ... Arjan, the tracepoint patch is merged already into drm-intel-next-queued, i.e. powertop integration is good to go. Thanks, Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
