Hi, Resending to have a second chance of getting feedback on my feedback ;-) Nicolas Dechesne suggested me to share feedback on our "first-time" use of the tool. I was using v1.0.0.rc1 so some points may no longer be relevant. I don't want to focus on the good points of the tool but we were clearly impressed by the speed/flexibility of the tool, on-the-fly update of active processes when we zoom/unzoom, exhaustiveness of trace support, plugin mechanism ... Well it is clearly made to perform an investigation efficiently. And this is more than a tool, this is a framework. However, there are some points, which could be worth discussing (here is an example of custom visualization we do with matplotlib http://i.imgur.com/XsdlS.png): - time scale is quite big. But there is no indication of exact location of the pointer in bottom bar. This proved efficient when investigating multimedia glitches rather than constantly resorting to trace itself - having 1 different color per core could ease reading of the graph (rather than zooming to check core id) - few things, which are questionable in terms of interest: * we also like seeing idle time at the bottom. I tried to move cpu C-states line at the bottom but it does not seem possible. Well, we can simply move them by editing order of plugin in code I guess * we also sort threads from the least running at the top to the most running at bottom. It helps seeing patterns. But, the fact that your tool can show dynamically only the active threads is really nice, it compensates that need probably * we link all processes on 1 core by a wake event. This makes viewing long record unusable but after zooming it helps. Don't know if that would not impact perf, even as an optional feature I also noted: - this version is not ported to latest workqueue trace format after Tejun Heo's workqueue rework (I use K3.0). The "stop" trace does not contain all information from "start" trace so I hacked quickly the use of a dictionary ... then I realized "timers" are an example of what is expected. I'll update my patch accordingly in case it's not already available kworker/u:3-814 [001] 806.162109: workqueue_execute_start: work struct c7a45b1c: function xxx kworker/u:3-814 [001] 806.162140: workqueue_execute_end: work struct c7a45b1c However, I didn't check how to integrate the "yellow" color when workqueue is pre-empted. But not sure it was available on previous workqueue trace - a more general problem that does not come from your tool: ftrace does not give init value of transition metrics like MPU frequency so no value if no transition. We could update pytimechart-record to fetch them if available from sysfs and add "fake" entry in logs. Currently we never really faced this as we collect metrics from systemtap so we fetch init values at tool start. Regards Fred OMAP Platform Business Unit - System Platform Engineering - Platform & Product Entitlement Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|