From: Pawel Moll <pawel.moll@arm.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Amit Daniel Kachhap <amit.kachhap@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Jean Delvare <khali@linux-fr.org>,
Steven Rostedt <rostedt@goodmis.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>, Jesper Juhl <jj@chaosbits.net>,
Thomas Renninger <trenn@suse.de>,
Jean Pihet <jean.pihet@newoldbits.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>
Subject: Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel
Date: Wed, 24 Oct 2012 16:37:27 +0000 [thread overview]
Message-ID: <1351096647.23327.64.camel@hornet> (raw)
In-Reply-To: <20121023220240.GA25895@roeck-us.net>
T24gVHVlLCAyMDEyLTEwLTIzIGF0IDIzOjAyICswMTAwLCBHdWVudGVyIFJvZWNrIHdyb3RlOgo+
ID4gVHJhZGl0aW9uYWxseSBzdWNoIGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIg
dmlhIGh3bW9uIHN5c2ZzCj4gPiBpbnRlcmZhY2UsIGFuZCB0aGF0J3MgZXhhY3RseSB3aGF0IEkg
ZGlkIGZvciAibXkiIHBsYXRmb3JtIC0gSSBoYXZlCj4gPiBhIC9zeXMvY2xhc3MvaHdtb24vaHdt
b24qL2RldmljZS9lbmVyZ3kqX2lucHV0IGFuZCB0aGlzIHdhcyBnb29kCj4gPiBlbm91Z2ggdG8g
ZHJhdyBwcmV0dHkgZ3JhcGhzIGluIHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4g
PiAKPiBPbmx5IGRyaXZlciBzdXBwb3J0aW5nICJlbmVyZ3kiIG91dHB1dCBzbyBmYXIgaXMgaWJt
YWVtLCBhbmQgdGhlIHJlcG9ydGVkIGVuZXJneQo+IGlzIHN1cHBvc2VkIHRvIGJlIGN1bXVsYXRp
dmUsIGFzIGluIGVuZXJneSA9IHBvd2VyICogdGltZS4gRG8geW91IG1lYW4gcG93ZXIsCj4gcG9z
c2libHkgPwoKU28gdGhlIHZleHByZXNzIHdvdWxkIGJlIHRoZSBzZWNvbmQgb25lLCB0aGFuIDot
KSBhcyB0aGUgZW5lcmd5CiJtb25pdG9yIiBhY3R1YWxseSBvbiB0aGUgbGF0ZXN0IHRpbGVzIHJl
cG9ydHMgNjQtYml0IHZhbHVlIG9mCm1pY3JvSm91bGVzIGNvbnN1bWVkIChvciBwcm9kdWNlZCkg
c2luY2UgdGhlIHBvd2VyLXVwLgoKU29tZSBvZiB0aGUgb2xkZXIgYm9hcmRzIHdlcmUgYWJsZSB0
byByZXBvcnQgaW5zdGFudCBwb3dlciwgYnV0IHRoaXMKbWV0cmljcyBpcyBsZXNzIHVzZWZ1bCBp
biBvdXIgY2FzZS4KCj4gPiBOb3cgSSBhbSBnZXR0aW5nIG5ldyByZXF1ZXN0cyB0byBkbyBtb3Jl
IHdpdGggdGhpcyBkYXRhLiBJbiBwYXJ0aWN1bGFyCj4gPiBJJ20gYXNrZWQgaG93IHRvIGFkZCBz
dWNoIGluZm9ybWF0aW9uIHRvIGZ0cmFjZS9wZXJmIG91dHB1dC4gVGhlIHNlY29uZAo+ID4gbW9z
dCBmcmVxdWVudCByZXF1ZXN0IGlzIGFib3V0IHByb3ZpZGluZyBpdCB0byBhICJlbmVyZ3kgYXdh
cmUiCj4gPiBjcHVmcmVxIGdvdmVybm9yLgo+IAo+IEFueXRoaW5nIGVuZXJneSByZWxhdGVkIHdv
dWxkIGhhdmUgdG8gYmUgYWxvbmcgdGhlIGxpbmUgb2YgImRvIHNvbWV0aGluZyBhZnRlciBhCj4g
Y2VydGFpbiBhbW91bnQgb2Ygd29yayBoYXMgYmVlbiBwZXJmb3JtZWQiLCB3aGljaCBhdCBsZWFz
dCBhdCB0aGUgc3VyZmFjZSBkb2VzCj4gbm90IG1ha2UgbXVjaCBzZW5zZSB0byBtZSwgdW5sZXNz
IHlvdSBtZWFuIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZSBvZiBhCj4gcHJvY2VzcyBzY2hlZHVs
ZXIgd2hpY2ggc2NoZWR1bGVzIGEgcHJvY2VzcyBub3QgYmFzZWQgb24gdGltZSBzbGljZXMgYnV0
IGJhc2VkCj4gb24gZW5lcmd5IGNvbnN1bWVkLCBpZSBpZiB5b3Ugd2FudCB0byBkZWZpbmUgYSB0
aW1lIHNsaWNlIG5vdCBpbiBtaWxsaS1zZWNvbmRzCj4gYnV0IGluIEpvdWxlLgoKQWN0dWFsbHkg
dGhlcmUgaXMgc29tZSByZXNlYXJjaCBiZWluZyBkb25lIGluIHRoaXMgZGlyZWN0aW9uLCBidXQg
aXQncwp3YXkgdG9vIGVhcmx5IHRvIGRyYXcgYW55IGNvbmNsdXNpb25zLi4uCgo+IElmIHNvLCBJ
IHdvdWxkIGFyZ3VlIHRoYXQgYSBzaW1pbGFyIGJlaGF2aW9yIGNvdWxkIGJlIGFjaGlldmVkIGJ5
IHZhcnlpbmcgdGhlCj4gZHVyYXRpb24gb2YgdGltZSBzbGljZXMgd2l0aCB0aGUgY3VycmVudCBD
UFUgc3BlZWQsIG9yIHNpbXBseSBieSB1c2luZyBjeWNsZQo+IGNvdW50IGluc3RlYWQgb2YgdGlt
ZSBhcyB0aW1lIHNsaWNlIHBhcmFtZXRlci4gTm90IHRoYXQgSSBhbSBzdXJlIGlmIHN1Y2ggYW4K
PiBhcHByb2FjaCB3b3VsZCByZWFsbHkgYmUgb2YgaW50ZXJlc3QgZm9yIGFueW9uZS4gCj4gCj4g
T3IgZG8geW91IHJlYWxseSBtZWFuIHBvd2VyLCBub3QgZW5lcmd5LCBzdWNoIGFzIGluICJyZWR1
Y2UgQ1BVIHNwZWVkIGlmIGl0cwo+IHBvd2VyIGNvbnN1bXB0aW9uIGlzIGFib3ZlIFggV2F0dCIg
PwoKVWguIFRvIGJlIGNvbXBsZXRlbHkgaG9uZXN0IEkgbXVzdCBhbnN3ZXI6IEknbSBub3Qgc3Vy
ZSBob3cgdGhlICJlbmVyZ3kKYXdhcmUiIGNwdWZyZXEgZ292ZXJub3IgaXMgc3VwcG9zZWQgdG8g
d29yay4gSSBoYXZlIGJlZW4gc2ltcGx5IGFza2VkIHRvCnByb3ZpZGUgdGhlIGRhdGEgaW4gc29t
ZSBzdGFuZGFyZCB3YXksIGlmIHBvc3NpYmxlLgoKPiBJIGFtIG5vdCBzdXJlIGhvdyB0aGlzIHdv
dWxkIGJlIGV4cGVjdGVkIHRvIHdvcmsuIGh3bW9uIGlzLCBieSBpdHMgdmVyeSBuYXR1cmUsCj4g
YSBwYXNzaXZlIHN1YnN5c3RlbTogSXQgZG9lc24ndCBkbyBhbnl0aGluZyB1bmxlc3MgZGF0YSBp
cyBleHBsaWNpdGx5IHJlcXVlc3RlZAo+IGZyb20gaXQuIEl0IGRvZXMgbm90IHVwZGF0ZSBhbiBh
dHRyaWJ1dGUgdW5sZXNzIHRoYXQgYXR0cmlidXRlIGlzIHJlYWQuCj4gVGhhdCBkb2VzIG5vdCBz
ZWVtIHRvIGZpdCB3ZWxsIHdpdGggdGhlIGlkZWEgb2YgdHJhY2luZyAtIHdoaWNoIGFzc3VtZXMK
PiB0aGF0IHNvbWUgYWN0aXZpdHkgaXMgaGFwcGVuaW5nLCB1bHRpbWF0ZWx5LCBhbGwgYnkgaXRz
ZWxmLCBwcmVzdW1hYmx5Cj4gcGVyaW9kaWNhbGx5LiBUaGUgaWRlYSB0byBoYXZlIGEgdXNlciBz
cGFjZSBhcHBsaWNhdGlvbiByZWFkIGh3bW9uIGRhdGEgb25seQo+IGZvciBpdCB0byB0cmlnZ2Vy
IHRyYWNlIGV2ZW50cyBkb2VzIG5vdCBzZWVtIHRvIGJlIHZlcnkgY29tcGVsbGluZyB0byBtZS4K
CldoYXQgSSBoYWQgaW4gbWluZCB3YXMgc2ltaWxhciB0byB3aGF0IGFkdDc0NzAgZHJpdmVyIGRv
ZXMuIFRoZSBkcml2ZXIKd291bGQgYXV0b21hdGljYWxseSBhY2Nlc3MgdGhlIGRldmljZSBldmVy
eSBub3cgYW5kIHRoZW4gdG8gdXBkYXRlIGl0J3MKaW50ZXJuYWwgc3RhdGUgYW5kIGdlbmVyYXRl
IHRoZSB0cmFjZSBldmVudCBvbiB0aGUgd2F5LiBUaGlzCmF1dG8tcmVmcmVzaCAiZmVhdHVyZSIg
aXMgcGFydGljdWxhcmx5IGFwcGVhbGluZyBmb3IgbWUsIGFzIG9uIHNvbWUgb2YKIm15IiBwbGF0
Zm9ybXMgY2FuIHRha2UgdXAgdG8gNTAwIG1pY3Jvc2Vjb25kcyB0byBhY3R1YWxseSBnZXQgdGhl
IGRhdGEuClNvIGRvaW5nIHRoaXMgaW4gYmFja2dyb3VuZCAoYW5kIHByb3ZpZGluZyB1c2VycyB3
aXRoIHRoZSBsYXN0IGtub3duCnZhbHVlIGluIHRoZSBtZWFudGltZSkgc2VlbXMgYXR0cmFjdGl2
ZS4KCj4gQW4gZXhjZXB0aW9uIGlzIGlmIGEgbW9uaXRvcmluZyBkZXZpY2Ugc3VwcHBvcnRzIGlu
dGVycnVwdHMsIGFuZCBpZiBpdHMgZHJpdmVyCj4gYWN0dWFsbHkgaW1wbGVtZW50cyB0aG9zZSBp
bnRlcnJ1cHRzLiBUaGlzIGlzLCBob3dldmVyLCBub3QgdGhlIGNhc2UgZm9yIG1vc3Qgb2YKPiB0
aGUgY3VycmVudCBkcml2ZXJzIChpZiBhbnkpLCBtb3N0bHkgYmVjYXVzZSBpbnRlcnJ1cHQgc3Vw
cG9ydCBmb3IgaGFyZHdhcmUKPiBtb25pdG9yaW5nIGRldmljZXMgaXMgdmVyeSBwbGF0Zm9ybSBk
ZXBlbmRlbnQgYW5kIHRodXMgZGlmZmljdWx0IHRvIGltcGxlbWVudC4KCkludGVyZXN0aW5nbHkg
ZW5vdWdoIHRoZSBuZXdlc3QgdmVyc2lvbiBvZiBvdXIgcGxhdGZvcm0gY29udHJvbCBtaWNybwoo
ZG9pbmcgdGhlIGVuZXJneSBtb25pdG9yaW5nIGFzIHdlbGwpIGNhbiBnZW5lcmF0ZSBhbmQgaW50
ZXJydXB0IHdoZW4gYQp0cmFuc2FjdGlvbiBpcyBmaW5pc2hlZCwgc28gSSB3YXMgcGxhbm5pbmcg
dG8gcGVyaW9kaWNhbGx5IHVwZGF0ZSB0aGUKYWxsIHNvcnQgb2YgdmFsdWVzLiBBbmQgYWdhaW4s
IGdlbmVyYXRpbmcgYSB0cmFjZSBldmVudCBvbiB0aGlzCm9wcG9ydHVuaXR5IHdvdWxkIGJlIHRy
aXZpYWwuCgo+ID4gT2YgY291cnNlIGEgcGFydGljdWxhciBkcml2ZXIgY291bGQgcmVnaXN0ZXIg
aXRzIG93biBwZXJmIFBNVSBvbiBpdHMKPiA+IG93bi4gSXQncyBjZXJ0YWlubHkgYW4gb3B0aW9u
LCBqdXN0IHZlcnkgc3Vib3B0aW1hbCBpbiBteSBvcGluaW9uLgo+ID4gT3IgbWF5YmUgbm90PyBN
YXliZSB0aGUgdGFzayBpcyBzbyBzcGVjaWFsaXplZCB0aGF0IGl0IG1ha2VzIHNlbnNlPwo+ID4g
Cj4gV2UgaGFkIGEgY291cGxlIG9mIGF0dGVtcHRzIHRvIHByb3ZpZGUgYW4gaW4ta2VybmVsIEFQ
SS4gVW5mb3J0dW5hdGVseSwKPiB0aGUgcmVzdWx0IHdhcywgYXQgbGVhc3Qgc28gZmFyLCBtb3Jl
IGNvbXBsZXhpdHkgb24gdGhlIGRyaXZlciBzaWRlLgo+IFNvIHRoZSBkaWZmaWN1bHR5IGlzIHJl
YWxseSB0byBkZWZpbmUgYW4gQVBJIHdoaWNoIGlzIHJlYWxseSBzaW1wbGUsIGFuZCBkb2VzCj4g
bm90IGp1c3QgY29tcGxpY2F0ZSBkcml2ZXIgZGV2ZWxvcG1lbnQgZm9yIGEgKHByZXN1bWFibHkp
IHJhcmUgdXNlIGNhc2UuCgpZZXMsIEkgYXBwcmVjaWF0ZSB0aGlzLiBUaGF0J3Mgd2h5IHRoaXMg
b3B0aW9uIGlzIGFjdHVhbGx5IG15IGxlYXN0CmZhdm91cml0ZS4gQW55d2F5LCB3aGF0IEkgd2Fz
IHRoaW5raW5nIGFib3V0IHdhcyBqdXN0IGEgdGhpbiBzaGluIHRoYXQKKmNhbiogYmUgdXNlZCBi
eSBhIGRyaXZlciB0byByZWdpc3RlciBzb21lIHBhcnRpY3VsYXIgdmFsdWUgd2l0aCB0aGUKY29y
ZSAoc28gaXQgY2FuIGJlIGVudW1lcmF0ZWQgYW5kIGFjY2Vzc2VkIGJ5IGluLWtlcm5lbCBjbGll
bnRzKSBhbmQgdGhlCmNvcmUgY291bGQgKG9yIG5vdCkgY3JlYXRlIGEgc3lzZnMgYXR0cmlidXRl
IGZvciB0aGlzIHZhbHVlIG9uIGJlaGFsZiBvZgp0aGUgZHJpdmVyLiBTZWVtcyBsaWdodHdlaWdo
dCBlbm91Z2gsIHVubGVzcyBwcmV2aW91cyBleHBlcmllbmNlCnN1Z2dlc3RzIG90aGVyd2lzZT8K
CkNoZWVycyEKClBhd2XFggoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMu
b3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNv
cnM
WARNING: multiple messages have this Message-ID (diff)
From: pawel.moll@arm.com (Pawel Moll)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] Energy/power monitoring within the kernel
Date: Wed, 24 Oct 2012 17:37:27 +0100 [thread overview]
Message-ID: <1351096647.23327.64.camel@hornet> (raw)
In-Reply-To: <20121023220240.GA25895@roeck-us.net>
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 graphs in userspace. Everyone was happy...
> >
> Only driver supporting "energy" output so far is ibmaem, and the reported energy
> is supposed to be cumulative, as in energy = power * time. Do you mean power,
> possibly ?
So the vexpress would be the second one, than :-) as the energy
"monitor" actually on the latest tiles reports 64-bit value of
microJoules consumed (or produced) since the power-up.
Some of the older boards were able to report instant power, but this
metrics is less useful in our case.
> > Now I am getting new requests to do more with this data. In particular
> > I'm asked how to add such information to ftrace/perf output. The second
> > most frequent request is about providing it to a "energy aware"
> > cpufreq governor.
>
> Anything energy related would have to be along the line of "do something after a
> certain amount of work has been performed", which at least at the surface does
> not make much sense to me, unless you mean something along the line of a
> process scheduler which schedules a process not based on time slices but based
> on energy consumed, ie if you want to define a time slice not in milli-seconds
> but in Joule.
Actually there is some research being done in this direction, but it's
way too early to draw any conclusions...
> If so, I would argue that a similar behavior could be achieved by varying the
> duration of time slices with the current CPU speed, or simply by using cycle
> count instead of time as time slice parameter. Not that I am sure if such an
> approach would really be of interest for anyone.
>
> Or do you really mean power, not energy, such as in "reduce CPU speed if its
> power consumption is above X Watt" ?
Uh. To be completely honest I must answer: I'm not sure how the "energy
aware" cpufreq governor is supposed to work. I have been simply asked to
provide the data in some standard way, if possible.
> I am not sure how this would be expected to work. hwmon is, by its very nature,
> a passive subsystem: It doesn't do anything unless data is explicitly requested
> from it. It does not update an attribute unless that attribute is read.
> That does not seem to fit well with the idea of tracing - which assumes
> that some activity is happening, ultimately, all by itself, presumably
> periodically. The idea to have a user space application read hwmon data only
> for it to trigger trace events does not seem to be very compelling to me.
What I had in mind was similar to what adt7470 driver does. The driver
would automatically access the device every now and then to update it's
internal state and generate the trace event on the way. This
auto-refresh "feature" is particularly appealing for me, as on some of
"my" platforms can take up to 500 microseconds to actually get the data.
So doing this in background (and providing users with the last known
value in the meantime) seems attractive.
> An exception is if a monitoring device suppports interrupts, and if its driver
> actually implements those interrupts. This is, however, not the case for most of
> the current drivers (if any), mostly because interrupt support for hardware
> monitoring devices is very platform dependent and thus difficult to implement.
Interestingly enough the newest version of our platform control micro
(doing the energy monitoring as well) can generate and interrupt when a
transaction is finished, so I was planning to periodically update the
all sort of values. And again, generating a trace event on this
opportunity would be trivial.
> > Of course a particular driver could register its own perf PMU on its
> > own. It's certainly an option, just very suboptimal in my opinion.
> > Or maybe not? Maybe the task is so specialized that it makes sense?
> >
> We had a couple of attempts to provide an in-kernel API. Unfortunately,
> the result was, at least so far, more complexity on the driver side.
> So the difficulty is really to define an API which is really simple, and does
> not just complicate driver development for a (presumably) rare use case.
Yes, I appreciate this. That's why this option is actually my least
favourite. Anyway, what I was thinking about was just a thin shin that
*can* be used by a driver to register some particular value with the
core (so it can be enumerated and accessed by in-kernel clients) and the
core could (or not) create a sysfs attribute for this value on behalf of
the driver. Seems lightweight enough, unless previous experience
suggests otherwise?
Cheers!
Pawe?
WARNING: multiple messages have this Message-ID (diff)
From: Pawel Moll <pawel.moll@arm.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Amit Daniel Kachhap <amit.kachhap@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Jean Delvare <khali@linux-fr.org>,
Steven Rostedt <rostedt@goodmis.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>, Jesper Juhl <jj@chaosbits.net>,
Thomas Renninger <trenn@suse.de>,
Jean Pihet <jean.pihet@newoldbits.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>
Subject: Re: [RFC] Energy/power monitoring within the kernel
Date: Wed, 24 Oct 2012 17:37:27 +0100 [thread overview]
Message-ID: <1351096647.23327.64.camel@hornet> (raw)
In-Reply-To: <20121023220240.GA25895@roeck-us.net>
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 graphs in userspace. Everyone was happy...
> >
> Only driver supporting "energy" output so far is ibmaem, and the reported energy
> is supposed to be cumulative, as in energy = power * time. Do you mean power,
> possibly ?
So the vexpress would be the second one, than :-) as the energy
"monitor" actually on the latest tiles reports 64-bit value of
microJoules consumed (or produced) since the power-up.
Some of the older boards were able to report instant power, but this
metrics is less useful in our case.
> > Now I am getting new requests to do more with this data. In particular
> > I'm asked how to add such information to ftrace/perf output. The second
> > most frequent request is about providing it to a "energy aware"
> > cpufreq governor.
>
> Anything energy related would have to be along the line of "do something after a
> certain amount of work has been performed", which at least at the surface does
> not make much sense to me, unless you mean something along the line of a
> process scheduler which schedules a process not based on time slices but based
> on energy consumed, ie if you want to define a time slice not in milli-seconds
> but in Joule.
Actually there is some research being done in this direction, but it's
way too early to draw any conclusions...
> If so, I would argue that a similar behavior could be achieved by varying the
> duration of time slices with the current CPU speed, or simply by using cycle
> count instead of time as time slice parameter. Not that I am sure if such an
> approach would really be of interest for anyone.
>
> Or do you really mean power, not energy, such as in "reduce CPU speed if its
> power consumption is above X Watt" ?
Uh. To be completely honest I must answer: I'm not sure how the "energy
aware" cpufreq governor is supposed to work. I have been simply asked to
provide the data in some standard way, if possible.
> I am not sure how this would be expected to work. hwmon is, by its very nature,
> a passive subsystem: It doesn't do anything unless data is explicitly requested
> from it. It does not update an attribute unless that attribute is read.
> That does not seem to fit well with the idea of tracing - which assumes
> that some activity is happening, ultimately, all by itself, presumably
> periodically. The idea to have a user space application read hwmon data only
> for it to trigger trace events does not seem to be very compelling to me.
What I had in mind was similar to what adt7470 driver does. The driver
would automatically access the device every now and then to update it's
internal state and generate the trace event on the way. This
auto-refresh "feature" is particularly appealing for me, as on some of
"my" platforms can take up to 500 microseconds to actually get the data.
So doing this in background (and providing users with the last known
value in the meantime) seems attractive.
> An exception is if a monitoring device suppports interrupts, and if its driver
> actually implements those interrupts. This is, however, not the case for most of
> the current drivers (if any), mostly because interrupt support for hardware
> monitoring devices is very platform dependent and thus difficult to implement.
Interestingly enough the newest version of our platform control micro
(doing the energy monitoring as well) can generate and interrupt when a
transaction is finished, so I was planning to periodically update the
all sort of values. And again, generating a trace event on this
opportunity would be trivial.
> > Of course a particular driver could register its own perf PMU on its
> > own. It's certainly an option, just very suboptimal in my opinion.
> > Or maybe not? Maybe the task is so specialized that it makes sense?
> >
> We had a couple of attempts to provide an in-kernel API. Unfortunately,
> the result was, at least so far, more complexity on the driver side.
> So the difficulty is really to define an API which is really simple, and does
> not just complicate driver development for a (presumably) rare use case.
Yes, I appreciate this. That's why this option is actually my least
favourite. Anyway, what I was thinking about was just a thin shin that
*can* be used by a driver to register some particular value with the
core (so it can be enumerated and accessed by in-kernel clients) and the
core could (or not) create a sysfs attribute for this value on behalf of
the driver. Seems lightweight enough, unless previous experience
suggests otherwise?
Cheers!
Paweł
next prev parent reply other threads:[~2012-10-24 16:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 17:30 [lm-sensors] [RFC] Energy/power monitoring within the kernel Pawel Moll
2012-10-23 17:30 ` Pawel Moll
2012-10-23 17:30 ` Pawel Moll
2012-10-23 17:43 ` [lm-sensors] " Steven Rostedt
2012-10-23 17:43 ` Steven Rostedt
2012-10-23 17:43 ` Steven Rostedt
2012-10-24 16:00 ` [lm-sensors] " Pawel Moll
2012-10-24 16:00 ` Pawel Moll
2012-10-24 16:00 ` Pawel Moll
2012-10-23 18:49 ` [lm-sensors] " Andy Green
2012-10-23 18:49 ` Andy Green
2012-10-23 18:49 ` Andy Green
2012-10-24 16:05 ` [lm-sensors] " Pawel Moll
2012-10-24 16:05 ` Pawel Moll
2012-10-24 16:05 ` Pawel Moll
2012-10-23 22:02 ` [lm-sensors] " Guenter Roeck
2012-10-23 22:02 ` Guenter Roeck
2012-10-23 22:02 ` Guenter Roeck
2012-10-24 16:37 ` Pawel Moll [this message]
2012-10-24 16:37 ` Pawel Moll
2012-10-24 16:37 ` Pawel Moll
2012-10-24 20:01 ` [lm-sensors] " Guenter Roeck
2012-10-24 20:01 ` Guenter Roeck
2012-10-24 20:01 ` Guenter Roeck
2012-10-24 0:40 ` [lm-sensors] " Thomas Renninger
2012-10-24 0:40 ` Thomas Renninger
2012-10-24 0:40 ` Thomas Renninger
2012-10-24 16:51 ` [lm-sensors] " Pawel Moll
2012-10-24 16:51 ` Pawel Moll
2012-10-24 16:51 ` Pawel Moll
2012-10-24 0:41 ` [lm-sensors] " Thomas Renninger
2012-10-24 0:41 ` Thomas Renninger
2012-10-24 0:41 ` Thomas Renninger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1351096647.23327.64.camel@hornet \
--to=pawel.moll@arm.com \
--cc=amit.kachhap@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=fweisbec@gmail.com \
--cc=jean.pihet@newoldbits.com \
--cc=jj@chaosbits.net \
--cc=khali@linux-fr.org \
--cc=linaro-dev@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=rui.zhang@intel.com \
--cc=trenn@suse.de \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.