On Tue, Aug 30, 2011 at 11:51 AM, Tony Mansson <tony.mans...@linaro.org> wrote: > Hello, > > On the topic of C-state statistics: > > For 11.09 there are BP:s to A) fix powertop for ARM and B) create an > Android app for running powertop in Android. By that I mean executing > a reconfigured but upstreamable powertop as a service and control it > from the app. > > I'd like input on usage patterns for powertop from all you PM experts > in order to design that app as useful as possible. I'd imagine that > the actual display (ncurses-based on other platforms) is cute and sure > we should have it, but is it really that useful? Isn't the most
The app in its current state is useful for *users* that might want to see: - what process causes the most wakeups? - is the system going to lower C-states and P-states? When it was first released, it caused a huge bunch of fixes to be made across the Linux stack (Gnome & KDE base libraries, apps, kernel), led to timer coalescing, etc. It allowed casual users to know what was going on in the system that was draining their battery so they could complain to developers (app and kernel). > important thing to get statistics between a starting and an ending > time while some test or use case is executed? This requirement is more developer-oriented and an important one too. > So I am thinking that prio 1 is "tap to start/stop logging" and saving > the set of result vectors for each measurement cycle to a file that > can be taken out and processed off-line into a diagram or whatever. Yes, but I don't see anything Android-specific in this. PMWG is working with the Validation Team on an energy measurement lab that'd allow us to do something like this across member boards. This could then be integrated into LAVA. So the question then becomes - can the same framework be used on a end-user product e.g. a phone, so we could just supply a .apk to allow control of the device and then run our tests. I think the answer is yes, but I can't commit to a delivery date because the framework itself is a donation from a member and we don't have access to it yet. Then all we'd need for android is a UI to fire a series of tests and show the end result. > Other ideas? I'd like to see energy measurement co-relate to system activity using perf/ftrace subsystem so that we can pin-point exactly what is going on at any time during a measurement. That is our medium-term goal - to make it easy for developers to instrument the power profile of their code. /Amit _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
