Thanks, I understand. This is why open source and communities are so important.
My main need was to know if some points were in a roadmap, we should of course contribute when we have specific need (as we intend to do for workqueue) Most points are "nice to have". And for more critical stuff, feasibility and simple guidance will be a good start. But we will have to analyze and rank our points first before coming back eventually to Chaco/pytimechart community for discussion. Honestly, we are globally still debating where we will have time to put efforts so I can't say more today ;-) Regards Fred OMAP Platform Business Unit - System Platform Engineering - Platform & Product Entitlement From: Pierre Tardy [mailto:[email protected]] Sent: Saturday, April 14, 2012 7:26 PM To: Turgis, Frederic Cc: [email protected]; Pihet-XID, Jean Subject: Re: pytimechart - first use feedback On Sat, Apr 14, 2012 at 6:11 PM, Turgis, Frederic <[email protected]> wrote: Hi, Resending to have a second chance of getting feedback on my feedback ;-) I apologize for not answering at your first feedback. I'm actually quite ashamed not being able to improve pytimechart to the point the users would like. I have changed my job position, so that I dont use pytimechart on a day to day basis anymore. So I am not annoyed to the point I would get motivated enough to improve things. :-) Pytimechart is an opensource tool, I took care for 1.0 to be well documented, and have code clear enough, so that people can hack it easily. Some of the features you need are very easy to implement (like adapt to new trace format), other will need more investment. I encourage you to look at the code and implement the features that will help you on your day to day job. Chaco is a nice library, with a helpful community. The time you invest in it you'll get rewarded by being more efficient at your debug work, and maybe more skills to build your own graphic tools. I'll integrate your patches very happily, just send me a pull request. Regards, Pierre 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 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
