diff for duplicates of <1351096647.23327.64.camel@hornet> diff --git a/a/1.txt b/N1/1.txt index 29734f6..b8c9873 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,88 +1,91 @@ -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 +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? diff --git a/a/content_digest b/N1/content_digest index 2f4ab12..c2c544e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,113 +1,101 @@ "ref\01351013449.9070.5.camel@hornet\0" "ref\020121023220240.GA25895@roeck-us.net\0" - "From\0Pawel Moll <pawel.moll@arm.com>\0" - "Subject\0Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel\0" - "Date\0Wed, 24 Oct 2012 16:37:27 +0000\0" - "To\0Guenter Roeck <linux@roeck-us.net>\0" - "Cc\0Amit 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>\0" + "From\0pawel.moll@arm.com (Pawel Moll)\0" + "Subject\0[RFC] Energy/power monitoring within the kernel\0" + "Date\0Wed, 24 Oct 2012 17:37:27 +0100\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" - "T24gVHVlLCAyMDEyLTEwLTIzIGF0IDIzOjAyICswMTAwLCBHdWVudGVyIFJvZWNrIHdyb3RlOgo+\n" - "ID4gVHJhZGl0aW9uYWxseSBzdWNoIGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIg\n" - "dmlhIGh3bW9uIHN5c2ZzCj4gPiBpbnRlcmZhY2UsIGFuZCB0aGF0J3MgZXhhY3RseSB3aGF0IEkg\n" - "ZGlkIGZvciAibXkiIHBsYXRmb3JtIC0gSSBoYXZlCj4gPiBhIC9zeXMvY2xhc3MvaHdtb24vaHdt\n" - "b24qL2RldmljZS9lbmVyZ3kqX2lucHV0IGFuZCB0aGlzIHdhcyBnb29kCj4gPiBlbm91Z2ggdG8g\n" - "ZHJhdyBwcmV0dHkgZ3JhcGhzIGluIHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4g\n" - "PiAKPiBPbmx5IGRyaXZlciBzdXBwb3J0aW5nICJlbmVyZ3kiIG91dHB1dCBzbyBmYXIgaXMgaWJt\n" - "YWVtLCBhbmQgdGhlIHJlcG9ydGVkIGVuZXJneQo+IGlzIHN1cHBvc2VkIHRvIGJlIGN1bXVsYXRp\n" - "dmUsIGFzIGluIGVuZXJneSA9IHBvd2VyICogdGltZS4gRG8geW91IG1lYW4gcG93ZXIsCj4gcG9z\n" - "c2libHkgPwoKU28gdGhlIHZleHByZXNzIHdvdWxkIGJlIHRoZSBzZWNvbmQgb25lLCB0aGFuIDot\n" - "KSBhcyB0aGUgZW5lcmd5CiJtb25pdG9yIiBhY3R1YWxseSBvbiB0aGUgbGF0ZXN0IHRpbGVzIHJl\n" - "cG9ydHMgNjQtYml0IHZhbHVlIG9mCm1pY3JvSm91bGVzIGNvbnN1bWVkIChvciBwcm9kdWNlZCkg\n" - "c2luY2UgdGhlIHBvd2VyLXVwLgoKU29tZSBvZiB0aGUgb2xkZXIgYm9hcmRzIHdlcmUgYWJsZSB0\n" - "byByZXBvcnQgaW5zdGFudCBwb3dlciwgYnV0IHRoaXMKbWV0cmljcyBpcyBsZXNzIHVzZWZ1bCBp\n" - "biBvdXIgY2FzZS4KCj4gPiBOb3cgSSBhbSBnZXR0aW5nIG5ldyByZXF1ZXN0cyB0byBkbyBtb3Jl\n" - "IHdpdGggdGhpcyBkYXRhLiBJbiBwYXJ0aWN1bGFyCj4gPiBJJ20gYXNrZWQgaG93IHRvIGFkZCBz\n" - "dWNoIGluZm9ybWF0aW9uIHRvIGZ0cmFjZS9wZXJmIG91dHB1dC4gVGhlIHNlY29uZAo+ID4gbW9z\n" - "dCBmcmVxdWVudCByZXF1ZXN0IGlzIGFib3V0IHByb3ZpZGluZyBpdCB0byBhICJlbmVyZ3kgYXdh\n" - "cmUiCj4gPiBjcHVmcmVxIGdvdmVybm9yLgo+IAo+IEFueXRoaW5nIGVuZXJneSByZWxhdGVkIHdv\n" - "dWxkIGhhdmUgdG8gYmUgYWxvbmcgdGhlIGxpbmUgb2YgImRvIHNvbWV0aGluZyBhZnRlciBhCj4g\n" - "Y2VydGFpbiBhbW91bnQgb2Ygd29yayBoYXMgYmVlbiBwZXJmb3JtZWQiLCB3aGljaCBhdCBsZWFz\n" - "dCBhdCB0aGUgc3VyZmFjZSBkb2VzCj4gbm90IG1ha2UgbXVjaCBzZW5zZSB0byBtZSwgdW5sZXNz\n" - "IHlvdSBtZWFuIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZSBvZiBhCj4gcHJvY2VzcyBzY2hlZHVs\n" - "ZXIgd2hpY2ggc2NoZWR1bGVzIGEgcHJvY2VzcyBub3QgYmFzZWQgb24gdGltZSBzbGljZXMgYnV0\n" - "IGJhc2VkCj4gb24gZW5lcmd5IGNvbnN1bWVkLCBpZSBpZiB5b3Ugd2FudCB0byBkZWZpbmUgYSB0\n" - "aW1lIHNsaWNlIG5vdCBpbiBtaWxsaS1zZWNvbmRzCj4gYnV0IGluIEpvdWxlLgoKQWN0dWFsbHkg\n" - "dGhlcmUgaXMgc29tZSByZXNlYXJjaCBiZWluZyBkb25lIGluIHRoaXMgZGlyZWN0aW9uLCBidXQg\n" - "aXQncwp3YXkgdG9vIGVhcmx5IHRvIGRyYXcgYW55IGNvbmNsdXNpb25zLi4uCgo+IElmIHNvLCBJ\n" - "IHdvdWxkIGFyZ3VlIHRoYXQgYSBzaW1pbGFyIGJlaGF2aW9yIGNvdWxkIGJlIGFjaGlldmVkIGJ5\n" - "IHZhcnlpbmcgdGhlCj4gZHVyYXRpb24gb2YgdGltZSBzbGljZXMgd2l0aCB0aGUgY3VycmVudCBD\n" - "UFUgc3BlZWQsIG9yIHNpbXBseSBieSB1c2luZyBjeWNsZQo+IGNvdW50IGluc3RlYWQgb2YgdGlt\n" - "ZSBhcyB0aW1lIHNsaWNlIHBhcmFtZXRlci4gTm90IHRoYXQgSSBhbSBzdXJlIGlmIHN1Y2ggYW4K\n" - "PiBhcHByb2FjaCB3b3VsZCByZWFsbHkgYmUgb2YgaW50ZXJlc3QgZm9yIGFueW9uZS4gCj4gCj4g\n" - "T3IgZG8geW91IHJlYWxseSBtZWFuIHBvd2VyLCBub3QgZW5lcmd5LCBzdWNoIGFzIGluICJyZWR1\n" - "Y2UgQ1BVIHNwZWVkIGlmIGl0cwo+IHBvd2VyIGNvbnN1bXB0aW9uIGlzIGFib3ZlIFggV2F0dCIg\n" - "PwoKVWguIFRvIGJlIGNvbXBsZXRlbHkgaG9uZXN0IEkgbXVzdCBhbnN3ZXI6IEknbSBub3Qgc3Vy\n" - "ZSBob3cgdGhlICJlbmVyZ3kKYXdhcmUiIGNwdWZyZXEgZ292ZXJub3IgaXMgc3VwcG9zZWQgdG8g\n" - "d29yay4gSSBoYXZlIGJlZW4gc2ltcGx5IGFza2VkIHRvCnByb3ZpZGUgdGhlIGRhdGEgaW4gc29t\n" - "ZSBzdGFuZGFyZCB3YXksIGlmIHBvc3NpYmxlLgoKPiBJIGFtIG5vdCBzdXJlIGhvdyB0aGlzIHdv\n" - "dWxkIGJlIGV4cGVjdGVkIHRvIHdvcmsuIGh3bW9uIGlzLCBieSBpdHMgdmVyeSBuYXR1cmUsCj4g\n" - "YSBwYXNzaXZlIHN1YnN5c3RlbTogSXQgZG9lc24ndCBkbyBhbnl0aGluZyB1bmxlc3MgZGF0YSBp\n" - "cyBleHBsaWNpdGx5IHJlcXVlc3RlZAo+IGZyb20gaXQuIEl0IGRvZXMgbm90IHVwZGF0ZSBhbiBh\n" - "dHRyaWJ1dGUgdW5sZXNzIHRoYXQgYXR0cmlidXRlIGlzIHJlYWQuCj4gVGhhdCBkb2VzIG5vdCBz\n" - "ZWVtIHRvIGZpdCB3ZWxsIHdpdGggdGhlIGlkZWEgb2YgdHJhY2luZyAtIHdoaWNoIGFzc3VtZXMK\n" - "PiB0aGF0IHNvbWUgYWN0aXZpdHkgaXMgaGFwcGVuaW5nLCB1bHRpbWF0ZWx5LCBhbGwgYnkgaXRz\n" - "ZWxmLCBwcmVzdW1hYmx5Cj4gcGVyaW9kaWNhbGx5LiBUaGUgaWRlYSB0byBoYXZlIGEgdXNlciBz\n" - "cGFjZSBhcHBsaWNhdGlvbiByZWFkIGh3bW9uIGRhdGEgb25seQo+IGZvciBpdCB0byB0cmlnZ2Vy\n" - "IHRyYWNlIGV2ZW50cyBkb2VzIG5vdCBzZWVtIHRvIGJlIHZlcnkgY29tcGVsbGluZyB0byBtZS4K\n" - "CldoYXQgSSBoYWQgaW4gbWluZCB3YXMgc2ltaWxhciB0byB3aGF0IGFkdDc0NzAgZHJpdmVyIGRv\n" - "ZXMuIFRoZSBkcml2ZXIKd291bGQgYXV0b21hdGljYWxseSBhY2Nlc3MgdGhlIGRldmljZSBldmVy\n" - "eSBub3cgYW5kIHRoZW4gdG8gdXBkYXRlIGl0J3MKaW50ZXJuYWwgc3RhdGUgYW5kIGdlbmVyYXRl\n" - "IHRoZSB0cmFjZSBldmVudCBvbiB0aGUgd2F5LiBUaGlzCmF1dG8tcmVmcmVzaCAiZmVhdHVyZSIg\n" - "aXMgcGFydGljdWxhcmx5IGFwcGVhbGluZyBmb3IgbWUsIGFzIG9uIHNvbWUgb2YKIm15IiBwbGF0\n" - "Zm9ybXMgY2FuIHRha2UgdXAgdG8gNTAwIG1pY3Jvc2Vjb25kcyB0byBhY3R1YWxseSBnZXQgdGhl\n" - "IGRhdGEuClNvIGRvaW5nIHRoaXMgaW4gYmFja2dyb3VuZCAoYW5kIHByb3ZpZGluZyB1c2VycyB3\n" - "aXRoIHRoZSBsYXN0IGtub3duCnZhbHVlIGluIHRoZSBtZWFudGltZSkgc2VlbXMgYXR0cmFjdGl2\n" - "ZS4KCj4gQW4gZXhjZXB0aW9uIGlzIGlmIGEgbW9uaXRvcmluZyBkZXZpY2Ugc3VwcHBvcnRzIGlu\n" - "dGVycnVwdHMsIGFuZCBpZiBpdHMgZHJpdmVyCj4gYWN0dWFsbHkgaW1wbGVtZW50cyB0aG9zZSBp\n" - "bnRlcnJ1cHRzLiBUaGlzIGlzLCBob3dldmVyLCBub3QgdGhlIGNhc2UgZm9yIG1vc3Qgb2YKPiB0\n" - "aGUgY3VycmVudCBkcml2ZXJzIChpZiBhbnkpLCBtb3N0bHkgYmVjYXVzZSBpbnRlcnJ1cHQgc3Vw\n" - "cG9ydCBmb3IgaGFyZHdhcmUKPiBtb25pdG9yaW5nIGRldmljZXMgaXMgdmVyeSBwbGF0Zm9ybSBk\n" - "ZXBlbmRlbnQgYW5kIHRodXMgZGlmZmljdWx0IHRvIGltcGxlbWVudC4KCkludGVyZXN0aW5nbHkg\n" - "ZW5vdWdoIHRoZSBuZXdlc3QgdmVyc2lvbiBvZiBvdXIgcGxhdGZvcm0gY29udHJvbCBtaWNybwoo\n" - "ZG9pbmcgdGhlIGVuZXJneSBtb25pdG9yaW5nIGFzIHdlbGwpIGNhbiBnZW5lcmF0ZSBhbmQgaW50\n" - "ZXJydXB0IHdoZW4gYQp0cmFuc2FjdGlvbiBpcyBmaW5pc2hlZCwgc28gSSB3YXMgcGxhbm5pbmcg\n" - "dG8gcGVyaW9kaWNhbGx5IHVwZGF0ZSB0aGUKYWxsIHNvcnQgb2YgdmFsdWVzLiBBbmQgYWdhaW4s\n" - "IGdlbmVyYXRpbmcgYSB0cmFjZSBldmVudCBvbiB0aGlzCm9wcG9ydHVuaXR5IHdvdWxkIGJlIHRy\n" - "aXZpYWwuCgo+ID4gT2YgY291cnNlIGEgcGFydGljdWxhciBkcml2ZXIgY291bGQgcmVnaXN0ZXIg\n" - "aXRzIG93biBwZXJmIFBNVSBvbiBpdHMKPiA+IG93bi4gSXQncyBjZXJ0YWlubHkgYW4gb3B0aW9u\n" - "LCBqdXN0IHZlcnkgc3Vib3B0aW1hbCBpbiBteSBvcGluaW9uLgo+ID4gT3IgbWF5YmUgbm90PyBN\n" - "YXliZSB0aGUgdGFzayBpcyBzbyBzcGVjaWFsaXplZCB0aGF0IGl0IG1ha2VzIHNlbnNlPwo+ID4g\n" - "Cj4gV2UgaGFkIGEgY291cGxlIG9mIGF0dGVtcHRzIHRvIHByb3ZpZGUgYW4gaW4ta2VybmVsIEFQ\n" - "SS4gVW5mb3J0dW5hdGVseSwKPiB0aGUgcmVzdWx0IHdhcywgYXQgbGVhc3Qgc28gZmFyLCBtb3Jl\n" - "IGNvbXBsZXhpdHkgb24gdGhlIGRyaXZlciBzaWRlLgo+IFNvIHRoZSBkaWZmaWN1bHR5IGlzIHJl\n" - "YWxseSB0byBkZWZpbmUgYW4gQVBJIHdoaWNoIGlzIHJlYWxseSBzaW1wbGUsIGFuZCBkb2VzCj4g\n" - "bm90IGp1c3QgY29tcGxpY2F0ZSBkcml2ZXIgZGV2ZWxvcG1lbnQgZm9yIGEgKHByZXN1bWFibHkp\n" - "IHJhcmUgdXNlIGNhc2UuCgpZZXMsIEkgYXBwcmVjaWF0ZSB0aGlzLiBUaGF0J3Mgd2h5IHRoaXMg\n" - "b3B0aW9uIGlzIGFjdHVhbGx5IG15IGxlYXN0CmZhdm91cml0ZS4gQW55d2F5LCB3aGF0IEkgd2Fz\n" - "IHRoaW5raW5nIGFib3V0IHdhcyBqdXN0IGEgdGhpbiBzaGluIHRoYXQKKmNhbiogYmUgdXNlZCBi\n" - "eSBhIGRyaXZlciB0byByZWdpc3RlciBzb21lIHBhcnRpY3VsYXIgdmFsdWUgd2l0aCB0aGUKY29y\n" - "ZSAoc28gaXQgY2FuIGJlIGVudW1lcmF0ZWQgYW5kIGFjY2Vzc2VkIGJ5IGluLWtlcm5lbCBjbGll\n" - "bnRzKSBhbmQgdGhlCmNvcmUgY291bGQgKG9yIG5vdCkgY3JlYXRlIGEgc3lzZnMgYXR0cmlidXRl\n" - "IGZvciB0aGlzIHZhbHVlIG9uIGJlaGFsZiBvZgp0aGUgZHJpdmVyLiBTZWVtcyBsaWdodHdlaWdo\n" - "dCBlbm91Z2gsIHVubGVzcyBwcmV2aW91cyBleHBlcmllbmNlCnN1Z2dlc3RzIG90aGVyd2lzZT8K\n" - "CkNoZWVycyEKClBhd2XFggoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f\n" - "X19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMu\n" - "b3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNv\n" - cnM + "On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote:\n" + "> > Traditionally such data should be exposed to the user via hwmon sysfs\n" + "> > interface, and that's exactly what I did for \"my\" platform - I have\n" + "> > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good\n" + "> > enough to draw pretty graphs in userspace. Everyone was happy...\n" + "> > \n" + "> Only driver supporting \"energy\" output so far is ibmaem, and the reported energy\n" + "> is supposed to be cumulative, as in energy = power * time. Do you mean power,\n" + "> possibly ?\n" + "\n" + "So the vexpress would be the second one, than :-) as the energy\n" + "\"monitor\" actually on the latest tiles reports 64-bit value of\n" + "microJoules consumed (or produced) since the power-up.\n" + "\n" + "Some of the older boards were able to report instant power, but this\n" + "metrics is less useful in our case.\n" + "\n" + "> > Now I am getting new requests to do more with this data. In particular\n" + "> > I'm asked how to add such information to ftrace/perf output. The second\n" + "> > most frequent request is about providing it to a \"energy aware\"\n" + "> > cpufreq governor.\n" + "> \n" + "> Anything energy related would have to be along the line of \"do something after a\n" + "> certain amount of work has been performed\", which at least at the surface does\n" + "> not make much sense to me, unless you mean something along the line of a\n" + "> process scheduler which schedules a process not based on time slices but based\n" + "> on energy consumed, ie if you want to define a time slice not in milli-seconds\n" + "> but in Joule.\n" + "\n" + "Actually there is some research being done in this direction, but it's\n" + "way too early to draw any conclusions...\n" + "\n" + "> If so, I would argue that a similar behavior could be achieved by varying the\n" + "> duration of time slices with the current CPU speed, or simply by using cycle\n" + "> count instead of time as time slice parameter. Not that I am sure if such an\n" + "> approach would really be of interest for anyone. \n" + "> \n" + "> Or do you really mean power, not energy, such as in \"reduce CPU speed if its\n" + "> power consumption is above X Watt\" ?\n" + "\n" + "Uh. To be completely honest I must answer: I'm not sure how the \"energy\n" + "aware\" cpufreq governor is supposed to work. I have been simply asked to\n" + "provide the data in some standard way, if possible.\n" + "\n" + "> I am not sure how this would be expected to work. hwmon is, by its very nature,\n" + "> a passive subsystem: It doesn't do anything unless data is explicitly requested\n" + "> from it. It does not update an attribute unless that attribute is read.\n" + "> That does not seem to fit well with the idea of tracing - which assumes\n" + "> that some activity is happening, ultimately, all by itself, presumably\n" + "> periodically. The idea to have a user space application read hwmon data only\n" + "> for it to trigger trace events does not seem to be very compelling to me.\n" + "\n" + "What I had in mind was similar to what adt7470 driver does. The driver\n" + "would automatically access the device every now and then to update it's\n" + "internal state and generate the trace event on the way. This\n" + "auto-refresh \"feature\" is particularly appealing for me, as on some of\n" + "\"my\" platforms can take up to 500 microseconds to actually get the data.\n" + "So doing this in background (and providing users with the last known\n" + "value in the meantime) seems attractive.\n" + "\n" + "> An exception is if a monitoring device suppports interrupts, and if its driver\n" + "> actually implements those interrupts. This is, however, not the case for most of\n" + "> the current drivers (if any), mostly because interrupt support for hardware\n" + "> monitoring devices is very platform dependent and thus difficult to implement.\n" + "\n" + "Interestingly enough the newest version of our platform control micro\n" + "(doing the energy monitoring as well) can generate and interrupt when a\n" + "transaction is finished, so I was planning to periodically update the\n" + "all sort of values. And again, generating a trace event on this\n" + "opportunity would be trivial.\n" + "\n" + "> > Of course a particular driver could register its own perf PMU on its\n" + "> > own. It's certainly an option, just very suboptimal in my opinion.\n" + "> > Or maybe not? Maybe the task is so specialized that it makes sense?\n" + "> > \n" + "> We had a couple of attempts to provide an in-kernel API. Unfortunately,\n" + "> the result was, at least so far, more complexity on the driver side.\n" + "> So the difficulty is really to define an API which is really simple, and does\n" + "> not just complicate driver development for a (presumably) rare use case.\n" + "\n" + "Yes, I appreciate this. That's why this option is actually my least\n" + "favourite. Anyway, what I was thinking about was just a thin shin that\n" + "*can* be used by a driver to register some particular value with the\n" + "core (so it can be enumerated and accessed by in-kernel clients) and the\n" + "core could (or not) create a sysfs attribute for this value on behalf of\n" + "the driver. Seems lightweight enough, unless previous experience\n" + "suggests otherwise?\n" + "\n" + "Cheers!\n" + "\n" + Pawe? -13af3b8f80c8bf0db8d8cbdf7d95091627a21b64e0e63722f81e843feac88a71 +730e7a20bce571b24a4c27532993aa92ea2fb8c19a44fa618dce6876809e68e2
diff --git a/a/1.txt b/N2/1.txt index 29734f6..aa5679b 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,88 +1,91 @@ -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 +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ł diff --git a/a/content_digest b/N2/content_digest index 2f4ab12..edb99b4 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,8 +1,8 @@ "ref\01351013449.9070.5.camel@hornet\0" "ref\020121023220240.GA25895@roeck-us.net\0" "From\0Pawel Moll <pawel.moll@arm.com>\0" - "Subject\0Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel\0" - "Date\0Wed, 24 Oct 2012 16:37:27 +0000\0" + "Subject\0Re: [RFC] Energy/power monitoring within the kernel\0" + "Date\0Wed, 24 Oct 2012 17:37:27 +0100\0" "To\0Guenter Roeck <linux@roeck-us.net>\0" "Cc\0Amit Daniel Kachhap <amit.kachhap@linaro.org>" Zhang Rui <rui.zhang@intel.com> @@ -21,93 +21,96 @@ " linaro-dev@lists.linaro.org <linaro-dev@lists.linaro.org>\0" "\00:1\0" "b\0" - "T24gVHVlLCAyMDEyLTEwLTIzIGF0IDIzOjAyICswMTAwLCBHdWVudGVyIFJvZWNrIHdyb3RlOgo+\n" - "ID4gVHJhZGl0aW9uYWxseSBzdWNoIGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIg\n" - "dmlhIGh3bW9uIHN5c2ZzCj4gPiBpbnRlcmZhY2UsIGFuZCB0aGF0J3MgZXhhY3RseSB3aGF0IEkg\n" - "ZGlkIGZvciAibXkiIHBsYXRmb3JtIC0gSSBoYXZlCj4gPiBhIC9zeXMvY2xhc3MvaHdtb24vaHdt\n" - "b24qL2RldmljZS9lbmVyZ3kqX2lucHV0IGFuZCB0aGlzIHdhcyBnb29kCj4gPiBlbm91Z2ggdG8g\n" - "ZHJhdyBwcmV0dHkgZ3JhcGhzIGluIHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4g\n" - "PiAKPiBPbmx5IGRyaXZlciBzdXBwb3J0aW5nICJlbmVyZ3kiIG91dHB1dCBzbyBmYXIgaXMgaWJt\n" - "YWVtLCBhbmQgdGhlIHJlcG9ydGVkIGVuZXJneQo+IGlzIHN1cHBvc2VkIHRvIGJlIGN1bXVsYXRp\n" - "dmUsIGFzIGluIGVuZXJneSA9IHBvd2VyICogdGltZS4gRG8geW91IG1lYW4gcG93ZXIsCj4gcG9z\n" - "c2libHkgPwoKU28gdGhlIHZleHByZXNzIHdvdWxkIGJlIHRoZSBzZWNvbmQgb25lLCB0aGFuIDot\n" - "KSBhcyB0aGUgZW5lcmd5CiJtb25pdG9yIiBhY3R1YWxseSBvbiB0aGUgbGF0ZXN0IHRpbGVzIHJl\n" - "cG9ydHMgNjQtYml0IHZhbHVlIG9mCm1pY3JvSm91bGVzIGNvbnN1bWVkIChvciBwcm9kdWNlZCkg\n" - "c2luY2UgdGhlIHBvd2VyLXVwLgoKU29tZSBvZiB0aGUgb2xkZXIgYm9hcmRzIHdlcmUgYWJsZSB0\n" - "byByZXBvcnQgaW5zdGFudCBwb3dlciwgYnV0IHRoaXMKbWV0cmljcyBpcyBsZXNzIHVzZWZ1bCBp\n" - "biBvdXIgY2FzZS4KCj4gPiBOb3cgSSBhbSBnZXR0aW5nIG5ldyByZXF1ZXN0cyB0byBkbyBtb3Jl\n" - "IHdpdGggdGhpcyBkYXRhLiBJbiBwYXJ0aWN1bGFyCj4gPiBJJ20gYXNrZWQgaG93IHRvIGFkZCBz\n" - "dWNoIGluZm9ybWF0aW9uIHRvIGZ0cmFjZS9wZXJmIG91dHB1dC4gVGhlIHNlY29uZAo+ID4gbW9z\n" - "dCBmcmVxdWVudCByZXF1ZXN0IGlzIGFib3V0IHByb3ZpZGluZyBpdCB0byBhICJlbmVyZ3kgYXdh\n" - "cmUiCj4gPiBjcHVmcmVxIGdvdmVybm9yLgo+IAo+IEFueXRoaW5nIGVuZXJneSByZWxhdGVkIHdv\n" - "dWxkIGhhdmUgdG8gYmUgYWxvbmcgdGhlIGxpbmUgb2YgImRvIHNvbWV0aGluZyBhZnRlciBhCj4g\n" - "Y2VydGFpbiBhbW91bnQgb2Ygd29yayBoYXMgYmVlbiBwZXJmb3JtZWQiLCB3aGljaCBhdCBsZWFz\n" - "dCBhdCB0aGUgc3VyZmFjZSBkb2VzCj4gbm90IG1ha2UgbXVjaCBzZW5zZSB0byBtZSwgdW5sZXNz\n" - "IHlvdSBtZWFuIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZSBvZiBhCj4gcHJvY2VzcyBzY2hlZHVs\n" - "ZXIgd2hpY2ggc2NoZWR1bGVzIGEgcHJvY2VzcyBub3QgYmFzZWQgb24gdGltZSBzbGljZXMgYnV0\n" - "IGJhc2VkCj4gb24gZW5lcmd5IGNvbnN1bWVkLCBpZSBpZiB5b3Ugd2FudCB0byBkZWZpbmUgYSB0\n" - "aW1lIHNsaWNlIG5vdCBpbiBtaWxsaS1zZWNvbmRzCj4gYnV0IGluIEpvdWxlLgoKQWN0dWFsbHkg\n" - "dGhlcmUgaXMgc29tZSByZXNlYXJjaCBiZWluZyBkb25lIGluIHRoaXMgZGlyZWN0aW9uLCBidXQg\n" - "aXQncwp3YXkgdG9vIGVhcmx5IHRvIGRyYXcgYW55IGNvbmNsdXNpb25zLi4uCgo+IElmIHNvLCBJ\n" - "IHdvdWxkIGFyZ3VlIHRoYXQgYSBzaW1pbGFyIGJlaGF2aW9yIGNvdWxkIGJlIGFjaGlldmVkIGJ5\n" - "IHZhcnlpbmcgdGhlCj4gZHVyYXRpb24gb2YgdGltZSBzbGljZXMgd2l0aCB0aGUgY3VycmVudCBD\n" - "UFUgc3BlZWQsIG9yIHNpbXBseSBieSB1c2luZyBjeWNsZQo+IGNvdW50IGluc3RlYWQgb2YgdGlt\n" - "ZSBhcyB0aW1lIHNsaWNlIHBhcmFtZXRlci4gTm90IHRoYXQgSSBhbSBzdXJlIGlmIHN1Y2ggYW4K\n" - "PiBhcHByb2FjaCB3b3VsZCByZWFsbHkgYmUgb2YgaW50ZXJlc3QgZm9yIGFueW9uZS4gCj4gCj4g\n" - "T3IgZG8geW91IHJlYWxseSBtZWFuIHBvd2VyLCBub3QgZW5lcmd5LCBzdWNoIGFzIGluICJyZWR1\n" - "Y2UgQ1BVIHNwZWVkIGlmIGl0cwo+IHBvd2VyIGNvbnN1bXB0aW9uIGlzIGFib3ZlIFggV2F0dCIg\n" - "PwoKVWguIFRvIGJlIGNvbXBsZXRlbHkgaG9uZXN0IEkgbXVzdCBhbnN3ZXI6IEknbSBub3Qgc3Vy\n" - "ZSBob3cgdGhlICJlbmVyZ3kKYXdhcmUiIGNwdWZyZXEgZ292ZXJub3IgaXMgc3VwcG9zZWQgdG8g\n" - "d29yay4gSSBoYXZlIGJlZW4gc2ltcGx5IGFza2VkIHRvCnByb3ZpZGUgdGhlIGRhdGEgaW4gc29t\n" - "ZSBzdGFuZGFyZCB3YXksIGlmIHBvc3NpYmxlLgoKPiBJIGFtIG5vdCBzdXJlIGhvdyB0aGlzIHdv\n" - "dWxkIGJlIGV4cGVjdGVkIHRvIHdvcmsuIGh3bW9uIGlzLCBieSBpdHMgdmVyeSBuYXR1cmUsCj4g\n" - "YSBwYXNzaXZlIHN1YnN5c3RlbTogSXQgZG9lc24ndCBkbyBhbnl0aGluZyB1bmxlc3MgZGF0YSBp\n" - "cyBleHBsaWNpdGx5IHJlcXVlc3RlZAo+IGZyb20gaXQuIEl0IGRvZXMgbm90IHVwZGF0ZSBhbiBh\n" - "dHRyaWJ1dGUgdW5sZXNzIHRoYXQgYXR0cmlidXRlIGlzIHJlYWQuCj4gVGhhdCBkb2VzIG5vdCBz\n" - "ZWVtIHRvIGZpdCB3ZWxsIHdpdGggdGhlIGlkZWEgb2YgdHJhY2luZyAtIHdoaWNoIGFzc3VtZXMK\n" - "PiB0aGF0IHNvbWUgYWN0aXZpdHkgaXMgaGFwcGVuaW5nLCB1bHRpbWF0ZWx5LCBhbGwgYnkgaXRz\n" - "ZWxmLCBwcmVzdW1hYmx5Cj4gcGVyaW9kaWNhbGx5LiBUaGUgaWRlYSB0byBoYXZlIGEgdXNlciBz\n" - "cGFjZSBhcHBsaWNhdGlvbiByZWFkIGh3bW9uIGRhdGEgb25seQo+IGZvciBpdCB0byB0cmlnZ2Vy\n" - "IHRyYWNlIGV2ZW50cyBkb2VzIG5vdCBzZWVtIHRvIGJlIHZlcnkgY29tcGVsbGluZyB0byBtZS4K\n" - "CldoYXQgSSBoYWQgaW4gbWluZCB3YXMgc2ltaWxhciB0byB3aGF0IGFkdDc0NzAgZHJpdmVyIGRv\n" - "ZXMuIFRoZSBkcml2ZXIKd291bGQgYXV0b21hdGljYWxseSBhY2Nlc3MgdGhlIGRldmljZSBldmVy\n" - "eSBub3cgYW5kIHRoZW4gdG8gdXBkYXRlIGl0J3MKaW50ZXJuYWwgc3RhdGUgYW5kIGdlbmVyYXRl\n" - "IHRoZSB0cmFjZSBldmVudCBvbiB0aGUgd2F5LiBUaGlzCmF1dG8tcmVmcmVzaCAiZmVhdHVyZSIg\n" - "aXMgcGFydGljdWxhcmx5IGFwcGVhbGluZyBmb3IgbWUsIGFzIG9uIHNvbWUgb2YKIm15IiBwbGF0\n" - "Zm9ybXMgY2FuIHRha2UgdXAgdG8gNTAwIG1pY3Jvc2Vjb25kcyB0byBhY3R1YWxseSBnZXQgdGhl\n" - "IGRhdGEuClNvIGRvaW5nIHRoaXMgaW4gYmFja2dyb3VuZCAoYW5kIHByb3ZpZGluZyB1c2VycyB3\n" - "aXRoIHRoZSBsYXN0IGtub3duCnZhbHVlIGluIHRoZSBtZWFudGltZSkgc2VlbXMgYXR0cmFjdGl2\n" - "ZS4KCj4gQW4gZXhjZXB0aW9uIGlzIGlmIGEgbW9uaXRvcmluZyBkZXZpY2Ugc3VwcHBvcnRzIGlu\n" - "dGVycnVwdHMsIGFuZCBpZiBpdHMgZHJpdmVyCj4gYWN0dWFsbHkgaW1wbGVtZW50cyB0aG9zZSBp\n" - "bnRlcnJ1cHRzLiBUaGlzIGlzLCBob3dldmVyLCBub3QgdGhlIGNhc2UgZm9yIG1vc3Qgb2YKPiB0\n" - "aGUgY3VycmVudCBkcml2ZXJzIChpZiBhbnkpLCBtb3N0bHkgYmVjYXVzZSBpbnRlcnJ1cHQgc3Vw\n" - "cG9ydCBmb3IgaGFyZHdhcmUKPiBtb25pdG9yaW5nIGRldmljZXMgaXMgdmVyeSBwbGF0Zm9ybSBk\n" - "ZXBlbmRlbnQgYW5kIHRodXMgZGlmZmljdWx0IHRvIGltcGxlbWVudC4KCkludGVyZXN0aW5nbHkg\n" - "ZW5vdWdoIHRoZSBuZXdlc3QgdmVyc2lvbiBvZiBvdXIgcGxhdGZvcm0gY29udHJvbCBtaWNybwoo\n" - "ZG9pbmcgdGhlIGVuZXJneSBtb25pdG9yaW5nIGFzIHdlbGwpIGNhbiBnZW5lcmF0ZSBhbmQgaW50\n" - "ZXJydXB0IHdoZW4gYQp0cmFuc2FjdGlvbiBpcyBmaW5pc2hlZCwgc28gSSB3YXMgcGxhbm5pbmcg\n" - "dG8gcGVyaW9kaWNhbGx5IHVwZGF0ZSB0aGUKYWxsIHNvcnQgb2YgdmFsdWVzLiBBbmQgYWdhaW4s\n" - "IGdlbmVyYXRpbmcgYSB0cmFjZSBldmVudCBvbiB0aGlzCm9wcG9ydHVuaXR5IHdvdWxkIGJlIHRy\n" - "aXZpYWwuCgo+ID4gT2YgY291cnNlIGEgcGFydGljdWxhciBkcml2ZXIgY291bGQgcmVnaXN0ZXIg\n" - "aXRzIG93biBwZXJmIFBNVSBvbiBpdHMKPiA+IG93bi4gSXQncyBjZXJ0YWlubHkgYW4gb3B0aW9u\n" - "LCBqdXN0IHZlcnkgc3Vib3B0aW1hbCBpbiBteSBvcGluaW9uLgo+ID4gT3IgbWF5YmUgbm90PyBN\n" - "YXliZSB0aGUgdGFzayBpcyBzbyBzcGVjaWFsaXplZCB0aGF0IGl0IG1ha2VzIHNlbnNlPwo+ID4g\n" - "Cj4gV2UgaGFkIGEgY291cGxlIG9mIGF0dGVtcHRzIHRvIHByb3ZpZGUgYW4gaW4ta2VybmVsIEFQ\n" - "SS4gVW5mb3J0dW5hdGVseSwKPiB0aGUgcmVzdWx0IHdhcywgYXQgbGVhc3Qgc28gZmFyLCBtb3Jl\n" - "IGNvbXBsZXhpdHkgb24gdGhlIGRyaXZlciBzaWRlLgo+IFNvIHRoZSBkaWZmaWN1bHR5IGlzIHJl\n" - "YWxseSB0byBkZWZpbmUgYW4gQVBJIHdoaWNoIGlzIHJlYWxseSBzaW1wbGUsIGFuZCBkb2VzCj4g\n" - "bm90IGp1c3QgY29tcGxpY2F0ZSBkcml2ZXIgZGV2ZWxvcG1lbnQgZm9yIGEgKHByZXN1bWFibHkp\n" - "IHJhcmUgdXNlIGNhc2UuCgpZZXMsIEkgYXBwcmVjaWF0ZSB0aGlzLiBUaGF0J3Mgd2h5IHRoaXMg\n" - "b3B0aW9uIGlzIGFjdHVhbGx5IG15IGxlYXN0CmZhdm91cml0ZS4gQW55d2F5LCB3aGF0IEkgd2Fz\n" - "IHRoaW5raW5nIGFib3V0IHdhcyBqdXN0IGEgdGhpbiBzaGluIHRoYXQKKmNhbiogYmUgdXNlZCBi\n" - "eSBhIGRyaXZlciB0byByZWdpc3RlciBzb21lIHBhcnRpY3VsYXIgdmFsdWUgd2l0aCB0aGUKY29y\n" - "ZSAoc28gaXQgY2FuIGJlIGVudW1lcmF0ZWQgYW5kIGFjY2Vzc2VkIGJ5IGluLWtlcm5lbCBjbGll\n" - "bnRzKSBhbmQgdGhlCmNvcmUgY291bGQgKG9yIG5vdCkgY3JlYXRlIGEgc3lzZnMgYXR0cmlidXRl\n" - "IGZvciB0aGlzIHZhbHVlIG9uIGJlaGFsZiBvZgp0aGUgZHJpdmVyLiBTZWVtcyBsaWdodHdlaWdo\n" - "dCBlbm91Z2gsIHVubGVzcyBwcmV2aW91cyBleHBlcmllbmNlCnN1Z2dlc3RzIG90aGVyd2lzZT8K\n" - "CkNoZWVycyEKClBhd2XFggoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f\n" - "X19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMu\n" - "b3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNv\n" - cnM + "On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote:\n" + "> > Traditionally such data should be exposed to the user via hwmon sysfs\n" + "> > interface, and that's exactly what I did for \"my\" platform - I have\n" + "> > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good\n" + "> > enough to draw pretty graphs in userspace. Everyone was happy...\n" + "> > \n" + "> Only driver supporting \"energy\" output so far is ibmaem, and the reported energy\n" + "> is supposed to be cumulative, as in energy = power * time. Do you mean power,\n" + "> possibly ?\n" + "\n" + "So the vexpress would be the second one, than :-) as the energy\n" + "\"monitor\" actually on the latest tiles reports 64-bit value of\n" + "microJoules consumed (or produced) since the power-up.\n" + "\n" + "Some of the older boards were able to report instant power, but this\n" + "metrics is less useful in our case.\n" + "\n" + "> > Now I am getting new requests to do more with this data. In particular\n" + "> > I'm asked how to add such information to ftrace/perf output. The second\n" + "> > most frequent request is about providing it to a \"energy aware\"\n" + "> > cpufreq governor.\n" + "> \n" + "> Anything energy related would have to be along the line of \"do something after a\n" + "> certain amount of work has been performed\", which at least at the surface does\n" + "> not make much sense to me, unless you mean something along the line of a\n" + "> process scheduler which schedules a process not based on time slices but based\n" + "> on energy consumed, ie if you want to define a time slice not in milli-seconds\n" + "> but in Joule.\n" + "\n" + "Actually there is some research being done in this direction, but it's\n" + "way too early to draw any conclusions...\n" + "\n" + "> If so, I would argue that a similar behavior could be achieved by varying the\n" + "> duration of time slices with the current CPU speed, or simply by using cycle\n" + "> count instead of time as time slice parameter. Not that I am sure if such an\n" + "> approach would really be of interest for anyone. \n" + "> \n" + "> Or do you really mean power, not energy, such as in \"reduce CPU speed if its\n" + "> power consumption is above X Watt\" ?\n" + "\n" + "Uh. To be completely honest I must answer: I'm not sure how the \"energy\n" + "aware\" cpufreq governor is supposed to work. I have been simply asked to\n" + "provide the data in some standard way, if possible.\n" + "\n" + "> I am not sure how this would be expected to work. hwmon is, by its very nature,\n" + "> a passive subsystem: It doesn't do anything unless data is explicitly requested\n" + "> from it. It does not update an attribute unless that attribute is read.\n" + "> That does not seem to fit well with the idea of tracing - which assumes\n" + "> that some activity is happening, ultimately, all by itself, presumably\n" + "> periodically. The idea to have a user space application read hwmon data only\n" + "> for it to trigger trace events does not seem to be very compelling to me.\n" + "\n" + "What I had in mind was similar to what adt7470 driver does. The driver\n" + "would automatically access the device every now and then to update it's\n" + "internal state and generate the trace event on the way. This\n" + "auto-refresh \"feature\" is particularly appealing for me, as on some of\n" + "\"my\" platforms can take up to 500 microseconds to actually get the data.\n" + "So doing this in background (and providing users with the last known\n" + "value in the meantime) seems attractive.\n" + "\n" + "> An exception is if a monitoring device suppports interrupts, and if its driver\n" + "> actually implements those interrupts. This is, however, not the case for most of\n" + "> the current drivers (if any), mostly because interrupt support for hardware\n" + "> monitoring devices is very platform dependent and thus difficult to implement.\n" + "\n" + "Interestingly enough the newest version of our platform control micro\n" + "(doing the energy monitoring as well) can generate and interrupt when a\n" + "transaction is finished, so I was planning to periodically update the\n" + "all sort of values. And again, generating a trace event on this\n" + "opportunity would be trivial.\n" + "\n" + "> > Of course a particular driver could register its own perf PMU on its\n" + "> > own. It's certainly an option, just very suboptimal in my opinion.\n" + "> > Or maybe not? Maybe the task is so specialized that it makes sense?\n" + "> > \n" + "> We had a couple of attempts to provide an in-kernel API. Unfortunately,\n" + "> the result was, at least so far, more complexity on the driver side.\n" + "> So the difficulty is really to define an API which is really simple, and does\n" + "> not just complicate driver development for a (presumably) rare use case.\n" + "\n" + "Yes, I appreciate this. That's why this option is actually my least\n" + "favourite. Anyway, what I was thinking about was just a thin shin that\n" + "*can* be used by a driver to register some particular value with the\n" + "core (so it can be enumerated and accessed by in-kernel clients) and the\n" + "core could (or not) create a sysfs attribute for this value on behalf of\n" + "the driver. Seems lightweight enough, unless previous experience\n" + "suggests otherwise?\n" + "\n" + "Cheers!\n" + "\n" + "Pawe\305\202" -13af3b8f80c8bf0db8d8cbdf7d95091627a21b64e0e63722f81e843feac88a71 +a8efaf9e5136994edb14184638acdff6247028ed09865ce19c39d9f6ecf25331
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.