On Sat, Sep 1, 2012 at 8:35 PM, Ben Widawsky ben@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@linux.intel.com Signed-off-by: Daniel Vetter daniel.vetter@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