Re: [RFC] Energy/power monitoring within the kernel

2012-10-24 Thread Guenter Roeck
On Wed, Oct 24, 2012 at 05:37:27PM +0100, Pawel Moll wrote: > On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote: > > > Traditionally such data should be exposed to the user via hwmon sysfs > > > interface, and that's exactly what I did for "my" platform - I have > > > a /sys/class/hwmon/hwmon*

Re: [RFC] Energy/power monitoring within the kernel

2012-10-24 Thread Pawel Moll
On Wed, 2012-10-24 at 01:40 +0100, Thomas Renninger wrote: > > More and more of people are getting interested in the subject of power > > (energy) consumption monitoring. We have some external tools like > > "battery simulators", energy probes etc., but some targets can measure > > their power usag

Re: [RFC] Energy/power monitoring within the kernel

2012-10-24 Thread Pawel Moll
On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote: > > Traditionally such data should be exposed to the user via hwmon sysfs > > interface, and that's exactly what I did for "my" platform - I have > > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good > > enough to draw pretty gr

Re: [RFC] Energy/power monitoring within the kernel

2012-10-24 Thread Pawel Moll
On Tue, 2012-10-23 at 19:49 +0100, Andy Green wrote: > A thought on that... from an SoC perspective there are other interesting > power rails than go to just the CPU core. For example DDR power and > rails involved with other IP units on the SoC such as 3D graphics unit. > So tying one number

Re: [RFC] Energy/power monitoring within the kernel

2012-10-24 Thread Pawel Moll
On Tue, 2012-10-23 at 18:43 +0100, Steven Rostedt wrote: > > <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361 > > > > One issue with this is that some external knowledge is required to > > relate a number to a processor core. Or maybe it's not an issue at all > > because it should be l

Re: [RFC] Energy/power monitoring within the kernel

2012-10-23 Thread Thomas Renninger
Hi, On Tuesday, October 23, 2012 06:30:49 PM Pawel Moll wrote: > Greetings All, > > More and more of people are getting interested in the subject of power > (energy) consumption monitoring. We have some external tools like > "battery simulators", energy probes etc., but some targets can measure >

Re: [RFC] Energy/power monitoring within the kernel

2012-10-23 Thread Thomas Renninger
Hi, On Tuesday, October 23, 2012 06:30:49 PM Pawel Moll wrote: > Greetings All, > > More and more of people are getting interested in the subject of power > (energy) consumption monitoring. We have some external tools like > "battery simulators", energy probes etc., but some targets can measure >

Re: [RFC] Energy/power monitoring within the kernel

2012-10-23 Thread Steven Rostedt
On Tue, 2012-10-23 at 18:30 +0100, Pawel Moll wrote: > > === Option 1: Trace event === > > This seems to be the "cheapest" option. Simply defining a trace event > that can be generated by a hwmon (or any other) driver makes the > interesting data immediately available to any ftrace/perf user. Of

Re: [RFC] Energy/power monitoring within the kernel

2012-10-23 Thread Guenter Roeck
On Tue, Oct 23, 2012 at 06:30:49PM +0100, Pawel Moll wrote: > Greetings All, > > More and more of people are getting interested in the subject of power > (energy) consumption monitoring. We have some external tools like > "battery simulators", energy probes etc., but some targets can measure > the

Re: [RFC] Energy/power monitoring within the kernel

2012-10-23 Thread Andy Green
On 10/23/12 19:30, the mail apparently from Pawel Moll included: Greetings All, More and more of people are getting interested in the subject of power (energy) consumption monitoring. We have some external tools like "battery simulators", energy probes etc., but some targets can measure their po

[RFC] Energy/power monitoring within the kernel

2012-10-23 Thread Pawel Moll
Greetings All, More and more of people are getting interested in the subject of power (energy) consumption monitoring. We have some external tools like "battery simulators", energy probes etc., but some targets can measure their power usage on their own. Traditionally such data should be exposed