diff for duplicates of <1351097507.23327.78.camel@hornet> diff --git a/a/1.txt b/N1/1.txt index 8e453d6..1e0f663 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,64 +1,74 @@ -T24gV2VkLCAyMDEyLTEwLTI0IGF0IDAxOjQwICswMTAwLCBUaG9tYXMgUmVubmluZ2VyIHdyb3Rl -Ogo+ID4gTW9yZSBhbmQgbW9yZSBvZiBwZW9wbGUgYXJlIGdldHRpbmcgaW50ZXJlc3RlZCBpbiB0 -aGUgc3ViamVjdCBvZiBwb3dlcgo+ID4gKGVuZXJneSkgY29uc3VtcHRpb24gbW9uaXRvcmluZy4g -V2UgaGF2ZSBzb21lIGV4dGVybmFsIHRvb2xzIGxpa2UKPiA+ICJiYXR0ZXJ5IHNpbXVsYXRvcnMi -LCBlbmVyZ3kgcHJvYmVzIGV0Yy4sIGJ1dCBzb21lIHRhcmdldHMgY2FuIG1lYXN1cmUKPiA+IHRo -ZWlyIHBvd2VyIHVzYWdlIG9uIHRoZWlyIG93bi4KPiA+IAo+ID4gVHJhZGl0aW9uYWxseSBzdWNo -IGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIgdmlhIGh3bW9uIHN5c2ZzCj4gPiBp -bnRlcmZhY2UsIGFuZCB0aGF0J3MgZXhhY3RseSB3aGF0IEkgZGlkIGZvciAibXkiIHBsYXRmb3Jt -IC0gSSBoYXZlCj4gPiBhIC9zeXMvY2xhc3MvaHdtb24vaHdtb24qL2RldmljZS9lbmVyZ3kqX2lu -cHV0IGFuZCB0aGlzIHdhcyBnb29kCj4gPiBlbm91Z2ggdG8gZHJhdyBwcmV0dHkgZ3JhcGhzIGlu -IHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4gPiAKPiA+IE5vdyBJIGFtIGdldHRp -bmcgbmV3IHJlcXVlc3RzIHRvIGRvIG1vcmUgd2l0aCB0aGlzIGRhdGEuIEluIHBhcnRpY3VsYXIK -PiA+IEknbSBhc2tlZCBob3cgdG8gYWRkIHN1Y2ggaW5mb3JtYXRpb24gdG8gZnRyYWNlL3BlcmYg -b3V0cHV0Lgo+IFdoeT8gV2hhdCBpcyB0aGUgZ2Fpbj8KPiAKPiBQZXJmIGV2ZW50cyBjYW4gYmUg -dHJpZ2dlcmVkIGF0IGFueSBwb2ludCBpbiB0aGUga2VybmVsLgo+IEEgY3B1ZnJlcSBldmVudCBp -cyB0cmlnZ2VyZWQgd2hlbiB0aGUgZnJlcXVlbmN5IGdldHMgY2hhbmdlZC4KPiBDUFUgaWRsZSBl -dmVudHMgYXJlIHRyaWdnZXJlZCB3aGVuIHRoZSBrZXJuZWwgcmVxdWVzdHMgdG8gZW50ZXIgYW4g -aWRsZSBzdGF0ZQo+IG9yIGV4aXRzIG9uZS4KPiAKPiBXaGVuIHdvdWxkIHlvdSB0cmlnZ2VyIGEg -dGhlcm1hbCBvciBhIHBvd2VyIGV2ZW50Pwo+IFRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0eSBvZiAo -Y3JpdGljYWwpIHRoZXJtYWwgbGltaXRzLgo+IEJ1dCBpZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3Jy -ZWN0bHkgeW91IHdhbnQgdGhpcyBmb3IgZGVidWdnaW5nIGFuZAo+IEkgZ3Vlc3MgeW91IGhhdmUg -ZXZlcnl0aGluZyBpbnRlcmVzdGluZyBvbmUgY2FuIGRvIHdpdGggdGVtcGVyYXR1cmUKPiB2YWx1 -ZXM6Cj4gICAtIHJlYWQgdGhlIHRlbXBlcmF0dXJlCj4gICAtIGRyYXcgc29tZSBuaWNlIGdyYXBo -cyBmcm9tIHRoZSByZXN1bHRzCj4gCj4gSG0sIEkgZ3Vlc3MgSSBrbm93IHdoYXQgeW91IHdhbnQg -dG8gZG86Cj4gSW4geW91ciB0ZW1wZXJhdHVyZS9lbmVyZ3kgZ3JhcGgsIHlvdSB3YW50IHRvIGhh -dmUgc29tZSBkb3RzCj4gd2hlbiByZWxldmFudCBIVyBzdGF0ZXMgKGZyZXF1ZW5jeSwgc2xlZXAg -c3RhdGVzLCAgRERSIHBvd2VyLC4uLikKPiBjaGFuZ2VkLiBUaGVuIHlvdSBhcmUgYWJsZSB0byBz -ZWUgdGhlIGVmZmVjdHMgb3ZlciBhIHRpbWVsaW5lLgo+IAo+IFNvIHlvdSBoYXZlIHRvIGJyaW5n -IHRoZSBleGlzdGluZyBmcmVxdWVuY3kvaWRsZSBwZXJmIGV2ZW50cyB0b2dldGhlcgo+IHdpdGgg -dGVtcGVyYXR1cmUgcmVhZGluZ3MKPiAKPiBDbGVhbmVzdCBzb2x1dGlvbiBjb3VsZCBiZSB0byBl -bmhhbmNlIHRoZSBleGlzaXRpbmcgdXNlcnNwYWNlIGFwcHMKPiAocHl0aW1lY2hhcnQvcGVyZiB0 -aW1lY2hhcnQpIGFuZCBsZXQgdGhlbSBhZGQgYW5vdGhlciBsaW5lCj4gKHRlbXBlcmF0dXJlL2Vu -ZXJneSksIGJ1dCB0aGUgZGF0YSB3b3VsZCBub3QgY29tZSBmcm9tIHBlcmYsIGJ1dAo+IGZyb20g -c3lzZnMvaHdtb24uCj4gTm90IHN1cmUgd2hldGhlciB0aGlzIHdvcmtzIG91dCB3aXRoIHRoZSB0 -aW1lY2hhcnQgdG9vbHMuCj4gQW55d2F5LCB0aGlzIHNvdW5kcyBsaWtlIGEgdXNlcnNwYWNlIG9u -bHkgcHJvYmxlbS4KCk9rLCBzbyBpdCBpcyBhY3R1YWxseSB3aGF0IEknbSB3b3JraW5nIG9uIHJp -Z2h0IG5vdy4gTm90IHdpdGggdGhlCnN0YW5kYXJkIHBlcmYgdG9vbCAodGhlcmUgYXJlIG90aGVy -IHVzZXJzIG9mIHRoYXQgQVBJIDstKSBidXQgaW5kZWVkIEknbQp0cnlpbmcgdG8gImVucmljaCIg -dGhlIGRhdGEgc3RyZWFtIGNvbWluZyBmcm9tIGtlcm5lbCB3aXRoIHVzZXItc3BhY2UKb3JpZ2lu -YXRpbmcgdmFsdWVzLiBJIGFtIGEgbGl0dGxlIGJpdCBjb25jZXJuZWQgYWJvdXQgZWZmZWN0IG9m -IGV4dHJhCnN5c2NhbGxzIChhY2Nlc3NpbmcgdGhlIHZhbHVlIGFuZCBnZXR0aW1lb2ZkYXkgdG8g -Z2VuZXJhdGUgYSB0aW1lc3RhbXApCmF0IGEgaGlnaGVyIHNhbXBsaW5nIHJhdGVzLCBidXQgbW9z -dCBsaWtlbHkgaXQgd29uJ3QgYmUgYSBwcm9ibGVtLiBDYW4KcmVwb3J0IG9uY2UgSSBrbm93IG1v -cmUsIGlmIHRoaXMgaXMgb2YgaW50ZXJlc3QgdG8gYW55b25lLgoKQW55d2F5LCB0aGVyZSBhcmUg -YXQgbGVhc3QgdHdvIGRlYnVnL3RyYWNlIHJlbGF0ZWQgdXNlIGNhc2VzIHRoYXQgY2FuCm5vdCBi -ZSBzYXRpc2ZpZWQgdGhhdCB3YXkgKG9mIGNvdXJzZSBvbmUgY291bGQgYXJndWUgYWJvdXQgdGhl -aXIKdXNlZnVsbmVzcyk6CgoxLiBmdHJhY2Utb3Zlci1uZXR3b3JrIChodHRwczovL2x3bi5uZXQv -QXJ0aWNsZXMvNDEwMjAwLykgd2hpY2ggaXMKcGFydGljdWxhcmx5IGFwcGVhbGluZyBmb3IgImVt -YmVkZGVkIHVzZXJzIiwgd2hlcmUgdGhlcmUncyB2aXJ0dWFsbHkgbm8KdXNlZnVsIHVzZXJzcGFj -ZSBhdmFpbGFibGUgKHRoaW5rIEFuZHJvaWQpLiBIZXJlIGEgKGZ1bmN0aW9uYWwpIHRyYWNlCmV2 -ZW50IGlzIGVtYmVkZGVkIGludG8gYSBub3JtYWwgdHJhY2UgYW5kIGF2YWlsYWJsZSAiZm9yIGZy -ZWUiIGF0IHRoZQpob3N0IHNpZGUuCgoyLiBwZXJmIGdyb3VwcyAtIHRoZSBnZW5lcmFsIGlkZWEg -aXMgdGhhdCBvbmUgZXZlbnQgKGxldCBpdCBiZSBjeWNsZQpjb3VudGVyIGludGVycnVwdCBvciBl -dmVuIGEgdGltZXIpIHRyaWdnZXJzIHJlYWQgb2Ygb3RoZXIgdmFsdWVzIChlZy4KY2FjaGUgY291 -bnRlciBvciAtIGluIHRoaXMgY2FzZSAtIGVuZXJneSBjb3VudGVyKS4gVGhlIGFpbSBpcyB0byBo -YXZlIGEKcmVndWxhciAic25hcHNob3RzIiBvZiB0aGUgc3lzdGVtIHN0YXRlLiBJJ20gbm90IHN1 -cmUgaWYgdGhlIHN0YW5kYXJkCnBlcmYgdG9vbCBjYW4gZG8gdGhpcywgYnV0IEkgZG8gOi0pCgpB -bmQgbGFzdCwgYnV0IG5vdCBsZWFzdCwgdGhlcmUgYXJlIHRoZSBub24tZGVidWcvdHJhY2UgY2xp -ZW50cyBmb3IKZW5lcmd5IGRhdGEgYXMgZGlzY3Vzc2VkIGluIG90aGVyIG1haWxzIGluIHRoaXMg -dGhyZWFkLiBPZiBjb3Vyc2UgdGhlCnRyYWNlIGV2ZW50IHdvbid0IHJlYWxseSBzYXRpc2Z5IHRo -ZWlyIG5lZWRzIGVpdGhlci4KClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjayEKClBhd2XFggoKCgpf -X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3Jz -IG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1z -ZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM +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 usage on their own. +> > +> > 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... +> > +> > 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. +> Why? What is the gain? +> +> Perf events can be triggered at any point in the kernel. +> A cpufreq event is triggered when the frequency gets changed. +> CPU idle events are triggered when the kernel requests to enter an idle state +> or exits one. +> +> When would you trigger a thermal or a power event? +> There is the possibility of (critical) thermal limits. +> But if I understand this correctly you want this for debugging and +> I guess you have everything interesting one can do with temperature +> values: +> - read the temperature +> - draw some nice graphs from the results +> +> Hm, I guess I know what you want to do: +> In your temperature/energy graph, you want to have some dots +> when relevant HW states (frequency, sleep states, DDR power,...) +> changed. Then you are able to see the effects over a timeline. +> +> So you have to bring the existing frequency/idle perf events together +> with temperature readings +> +> Cleanest solution could be to enhance the exisiting userspace apps +> (pytimechart/perf timechart) and let them add another line +> (temperature/energy), but the data would not come from perf, but +> from sysfs/hwmon. +> Not sure whether this works out with the timechart tools. +> Anyway, this sounds like a userspace only problem. + +Ok, so it is actually what I'm working on right now. Not with the +standard perf tool (there are other users of that API ;-) but indeed I'm +trying to "enrich" the data stream coming from kernel with user-space +originating values. I am a little bit concerned about effect of extra +syscalls (accessing the value and gettimeofday to generate a timestamp) +at a higher sampling rates, but most likely it won't be a problem. Can +report once I know more, if this is of interest to anyone. + +Anyway, there are at least two debug/trace related use cases that can +not be satisfied that way (of course one could argue about their +usefulness): + +1. ftrace-over-network (https://lwn.net/Articles/410200/) which is +particularly appealing for "embedded users", where there's virtually no +useful userspace available (think Android). Here a (functional) trace +event is embedded into a normal trace and available "for free" at the +host side. + +2. perf groups - the general idea is that one event (let it be cycle +counter interrupt or even a timer) triggers read of other values (eg. +cache counter or - in this case - energy counter). The aim is to have a +regular "snapshots" of the system state. I'm not sure if the standard +perf tool can do this, but I do :-) + +And last, but not least, there are the non-debug/trace clients for +energy data as discussed in other mails in this thread. Of course the +trace event won't really satisfy their needs either. + +Thanks for your feedback! + +Pawe? diff --git a/a/content_digest b/N1/content_digest index 7372eb5..7bc209f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,89 +1,84 @@ "ref\01351013449.9070.5.camel@hornet\0" "ref\04317776.evLpJapyim@hammer82.arch.suse.de\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:51:47 +0000\0" - "To\0Thomas Renninger <trenn@suse.de>\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> - Guenter Roeck <linux@roeck-us.net> - Steven Rostedt <rostedt@goodmis.org> - Frederic Weisbecker <fweisbec@gmail.com> - Ingo Molnar <mingo@elte.hu> - Jesper Juhl <jj@chaosbits.net> - 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:51:47 +0100\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" - "T24gV2VkLCAyMDEyLTEwLTI0IGF0IDAxOjQwICswMTAwLCBUaG9tYXMgUmVubmluZ2VyIHdyb3Rl\n" - "Ogo+ID4gTW9yZSBhbmQgbW9yZSBvZiBwZW9wbGUgYXJlIGdldHRpbmcgaW50ZXJlc3RlZCBpbiB0\n" - "aGUgc3ViamVjdCBvZiBwb3dlcgo+ID4gKGVuZXJneSkgY29uc3VtcHRpb24gbW9uaXRvcmluZy4g\n" - "V2UgaGF2ZSBzb21lIGV4dGVybmFsIHRvb2xzIGxpa2UKPiA+ICJiYXR0ZXJ5IHNpbXVsYXRvcnMi\n" - "LCBlbmVyZ3kgcHJvYmVzIGV0Yy4sIGJ1dCBzb21lIHRhcmdldHMgY2FuIG1lYXN1cmUKPiA+IHRo\n" - "ZWlyIHBvd2VyIHVzYWdlIG9uIHRoZWlyIG93bi4KPiA+IAo+ID4gVHJhZGl0aW9uYWxseSBzdWNo\n" - "IGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIgdmlhIGh3bW9uIHN5c2ZzCj4gPiBp\n" - "bnRlcmZhY2UsIGFuZCB0aGF0J3MgZXhhY3RseSB3aGF0IEkgZGlkIGZvciAibXkiIHBsYXRmb3Jt\n" - "IC0gSSBoYXZlCj4gPiBhIC9zeXMvY2xhc3MvaHdtb24vaHdtb24qL2RldmljZS9lbmVyZ3kqX2lu\n" - "cHV0IGFuZCB0aGlzIHdhcyBnb29kCj4gPiBlbm91Z2ggdG8gZHJhdyBwcmV0dHkgZ3JhcGhzIGlu\n" - "IHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4gPiAKPiA+IE5vdyBJIGFtIGdldHRp\n" - "bmcgbmV3IHJlcXVlc3RzIHRvIGRvIG1vcmUgd2l0aCB0aGlzIGRhdGEuIEluIHBhcnRpY3VsYXIK\n" - "PiA+IEknbSBhc2tlZCBob3cgdG8gYWRkIHN1Y2ggaW5mb3JtYXRpb24gdG8gZnRyYWNlL3BlcmYg\n" - "b3V0cHV0Lgo+IFdoeT8gV2hhdCBpcyB0aGUgZ2Fpbj8KPiAKPiBQZXJmIGV2ZW50cyBjYW4gYmUg\n" - "dHJpZ2dlcmVkIGF0IGFueSBwb2ludCBpbiB0aGUga2VybmVsLgo+IEEgY3B1ZnJlcSBldmVudCBp\n" - "cyB0cmlnZ2VyZWQgd2hlbiB0aGUgZnJlcXVlbmN5IGdldHMgY2hhbmdlZC4KPiBDUFUgaWRsZSBl\n" - "dmVudHMgYXJlIHRyaWdnZXJlZCB3aGVuIHRoZSBrZXJuZWwgcmVxdWVzdHMgdG8gZW50ZXIgYW4g\n" - "aWRsZSBzdGF0ZQo+IG9yIGV4aXRzIG9uZS4KPiAKPiBXaGVuIHdvdWxkIHlvdSB0cmlnZ2VyIGEg\n" - "dGhlcm1hbCBvciBhIHBvd2VyIGV2ZW50Pwo+IFRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0eSBvZiAo\n" - "Y3JpdGljYWwpIHRoZXJtYWwgbGltaXRzLgo+IEJ1dCBpZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3Jy\n" - "ZWN0bHkgeW91IHdhbnQgdGhpcyBmb3IgZGVidWdnaW5nIGFuZAo+IEkgZ3Vlc3MgeW91IGhhdmUg\n" - "ZXZlcnl0aGluZyBpbnRlcmVzdGluZyBvbmUgY2FuIGRvIHdpdGggdGVtcGVyYXR1cmUKPiB2YWx1\n" - "ZXM6Cj4gICAtIHJlYWQgdGhlIHRlbXBlcmF0dXJlCj4gICAtIGRyYXcgc29tZSBuaWNlIGdyYXBo\n" - "cyBmcm9tIHRoZSByZXN1bHRzCj4gCj4gSG0sIEkgZ3Vlc3MgSSBrbm93IHdoYXQgeW91IHdhbnQg\n" - "dG8gZG86Cj4gSW4geW91ciB0ZW1wZXJhdHVyZS9lbmVyZ3kgZ3JhcGgsIHlvdSB3YW50IHRvIGhh\n" - "dmUgc29tZSBkb3RzCj4gd2hlbiByZWxldmFudCBIVyBzdGF0ZXMgKGZyZXF1ZW5jeSwgc2xlZXAg\n" - "c3RhdGVzLCAgRERSIHBvd2VyLC4uLikKPiBjaGFuZ2VkLiBUaGVuIHlvdSBhcmUgYWJsZSB0byBz\n" - "ZWUgdGhlIGVmZmVjdHMgb3ZlciBhIHRpbWVsaW5lLgo+IAo+IFNvIHlvdSBoYXZlIHRvIGJyaW5n\n" - "IHRoZSBleGlzdGluZyBmcmVxdWVuY3kvaWRsZSBwZXJmIGV2ZW50cyB0b2dldGhlcgo+IHdpdGgg\n" - "dGVtcGVyYXR1cmUgcmVhZGluZ3MKPiAKPiBDbGVhbmVzdCBzb2x1dGlvbiBjb3VsZCBiZSB0byBl\n" - "bmhhbmNlIHRoZSBleGlzaXRpbmcgdXNlcnNwYWNlIGFwcHMKPiAocHl0aW1lY2hhcnQvcGVyZiB0\n" - "aW1lY2hhcnQpIGFuZCBsZXQgdGhlbSBhZGQgYW5vdGhlciBsaW5lCj4gKHRlbXBlcmF0dXJlL2Vu\n" - "ZXJneSksIGJ1dCB0aGUgZGF0YSB3b3VsZCBub3QgY29tZSBmcm9tIHBlcmYsIGJ1dAo+IGZyb20g\n" - "c3lzZnMvaHdtb24uCj4gTm90IHN1cmUgd2hldGhlciB0aGlzIHdvcmtzIG91dCB3aXRoIHRoZSB0\n" - "aW1lY2hhcnQgdG9vbHMuCj4gQW55d2F5LCB0aGlzIHNvdW5kcyBsaWtlIGEgdXNlcnNwYWNlIG9u\n" - "bHkgcHJvYmxlbS4KCk9rLCBzbyBpdCBpcyBhY3R1YWxseSB3aGF0IEknbSB3b3JraW5nIG9uIHJp\n" - "Z2h0IG5vdy4gTm90IHdpdGggdGhlCnN0YW5kYXJkIHBlcmYgdG9vbCAodGhlcmUgYXJlIG90aGVy\n" - "IHVzZXJzIG9mIHRoYXQgQVBJIDstKSBidXQgaW5kZWVkIEknbQp0cnlpbmcgdG8gImVucmljaCIg\n" - "dGhlIGRhdGEgc3RyZWFtIGNvbWluZyBmcm9tIGtlcm5lbCB3aXRoIHVzZXItc3BhY2UKb3JpZ2lu\n" - "YXRpbmcgdmFsdWVzLiBJIGFtIGEgbGl0dGxlIGJpdCBjb25jZXJuZWQgYWJvdXQgZWZmZWN0IG9m\n" - "IGV4dHJhCnN5c2NhbGxzIChhY2Nlc3NpbmcgdGhlIHZhbHVlIGFuZCBnZXR0aW1lb2ZkYXkgdG8g\n" - "Z2VuZXJhdGUgYSB0aW1lc3RhbXApCmF0IGEgaGlnaGVyIHNhbXBsaW5nIHJhdGVzLCBidXQgbW9z\n" - "dCBsaWtlbHkgaXQgd29uJ3QgYmUgYSBwcm9ibGVtLiBDYW4KcmVwb3J0IG9uY2UgSSBrbm93IG1v\n" - "cmUsIGlmIHRoaXMgaXMgb2YgaW50ZXJlc3QgdG8gYW55b25lLgoKQW55d2F5LCB0aGVyZSBhcmUg\n" - "YXQgbGVhc3QgdHdvIGRlYnVnL3RyYWNlIHJlbGF0ZWQgdXNlIGNhc2VzIHRoYXQgY2FuCm5vdCBi\n" - "ZSBzYXRpc2ZpZWQgdGhhdCB3YXkgKG9mIGNvdXJzZSBvbmUgY291bGQgYXJndWUgYWJvdXQgdGhl\n" - "aXIKdXNlZnVsbmVzcyk6CgoxLiBmdHJhY2Utb3Zlci1uZXR3b3JrIChodHRwczovL2x3bi5uZXQv\n" - "QXJ0aWNsZXMvNDEwMjAwLykgd2hpY2ggaXMKcGFydGljdWxhcmx5IGFwcGVhbGluZyBmb3IgImVt\n" - "YmVkZGVkIHVzZXJzIiwgd2hlcmUgdGhlcmUncyB2aXJ0dWFsbHkgbm8KdXNlZnVsIHVzZXJzcGFj\n" - "ZSBhdmFpbGFibGUgKHRoaW5rIEFuZHJvaWQpLiBIZXJlIGEgKGZ1bmN0aW9uYWwpIHRyYWNlCmV2\n" - "ZW50IGlzIGVtYmVkZGVkIGludG8gYSBub3JtYWwgdHJhY2UgYW5kIGF2YWlsYWJsZSAiZm9yIGZy\n" - "ZWUiIGF0IHRoZQpob3N0IHNpZGUuCgoyLiBwZXJmIGdyb3VwcyAtIHRoZSBnZW5lcmFsIGlkZWEg\n" - "aXMgdGhhdCBvbmUgZXZlbnQgKGxldCBpdCBiZSBjeWNsZQpjb3VudGVyIGludGVycnVwdCBvciBl\n" - "dmVuIGEgdGltZXIpIHRyaWdnZXJzIHJlYWQgb2Ygb3RoZXIgdmFsdWVzIChlZy4KY2FjaGUgY291\n" - "bnRlciBvciAtIGluIHRoaXMgY2FzZSAtIGVuZXJneSBjb3VudGVyKS4gVGhlIGFpbSBpcyB0byBo\n" - "YXZlIGEKcmVndWxhciAic25hcHNob3RzIiBvZiB0aGUgc3lzdGVtIHN0YXRlLiBJJ20gbm90IHN1\n" - "cmUgaWYgdGhlIHN0YW5kYXJkCnBlcmYgdG9vbCBjYW4gZG8gdGhpcywgYnV0IEkgZG8gOi0pCgpB\n" - "bmQgbGFzdCwgYnV0IG5vdCBsZWFzdCwgdGhlcmUgYXJlIHRoZSBub24tZGVidWcvdHJhY2UgY2xp\n" - "ZW50cyBmb3IKZW5lcmd5IGRhdGEgYXMgZGlzY3Vzc2VkIGluIG90aGVyIG1haWxzIGluIHRoaXMg\n" - "dGhyZWFkLiBPZiBjb3Vyc2UgdGhlCnRyYWNlIGV2ZW50IHdvbid0IHJlYWxseSBzYXRpc2Z5IHRo\n" - "ZWlyIG5lZWRzIGVpdGhlci4KClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjayEKClBhd2XFggoKCgpf\n" - "X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3Jz\n" - "IG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1z\n" - ZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM + "On Wed, 2012-10-24 at 01:40 +0100, Thomas Renninger wrote:\n" + "> > More and more of people are getting interested in the subject of power\n" + "> > (energy) consumption monitoring. We have some external tools like\n" + "> > \"battery simulators\", energy probes etc., but some targets can measure\n" + "> > their power usage on their own.\n" + "> > \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" + "> > 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.\n" + "> Why? What is the gain?\n" + "> \n" + "> Perf events can be triggered at any point in the kernel.\n" + "> A cpufreq event is triggered when the frequency gets changed.\n" + "> CPU idle events are triggered when the kernel requests to enter an idle state\n" + "> or exits one.\n" + "> \n" + "> When would you trigger a thermal or a power event?\n" + "> There is the possibility of (critical) thermal limits.\n" + "> But if I understand this correctly you want this for debugging and\n" + "> I guess you have everything interesting one can do with temperature\n" + "> values:\n" + "> - read the temperature\n" + "> - draw some nice graphs from the results\n" + "> \n" + "> Hm, I guess I know what you want to do:\n" + "> In your temperature/energy graph, you want to have some dots\n" + "> when relevant HW states (frequency, sleep states, DDR power,...)\n" + "> changed. Then you are able to see the effects over a timeline.\n" + "> \n" + "> So you have to bring the existing frequency/idle perf events together\n" + "> with temperature readings\n" + "> \n" + "> Cleanest solution could be to enhance the exisiting userspace apps\n" + "> (pytimechart/perf timechart) and let them add another line\n" + "> (temperature/energy), but the data would not come from perf, but\n" + "> from sysfs/hwmon.\n" + "> Not sure whether this works out with the timechart tools.\n" + "> Anyway, this sounds like a userspace only problem.\n" + "\n" + "Ok, so it is actually what I'm working on right now. Not with the\n" + "standard perf tool (there are other users of that API ;-) but indeed I'm\n" + "trying to \"enrich\" the data stream coming from kernel with user-space\n" + "originating values. I am a little bit concerned about effect of extra\n" + "syscalls (accessing the value and gettimeofday to generate a timestamp)\n" + "at a higher sampling rates, but most likely it won't be a problem. Can\n" + "report once I know more, if this is of interest to anyone.\n" + "\n" + "Anyway, there are at least two debug/trace related use cases that can\n" + "not be satisfied that way (of course one could argue about their\n" + "usefulness):\n" + "\n" + "1. ftrace-over-network (https://lwn.net/Articles/410200/) which is\n" + "particularly appealing for \"embedded users\", where there's virtually no\n" + "useful userspace available (think Android). Here a (functional) trace\n" + "event is embedded into a normal trace and available \"for free\" at the\n" + "host side.\n" + "\n" + "2. perf groups - the general idea is that one event (let it be cycle\n" + "counter interrupt or even a timer) triggers read of other values (eg.\n" + "cache counter or - in this case - energy counter). The aim is to have a\n" + "regular \"snapshots\" of the system state. I'm not sure if the standard\n" + "perf tool can do this, but I do :-)\n" + "\n" + "And last, but not least, there are the non-debug/trace clients for\n" + "energy data as discussed in other mails in this thread. Of course the\n" + "trace event won't really satisfy their needs either.\n" + "\n" + "Thanks for your feedback!\n" + "\n" + Pawe? -6f849b5939a10614c0b3bebdc128aac40becd3f1cccd5d86b48f204ba613d6f0 +a877e7bd6d96dc37fac4ce1887d6acd882c5c456dee7ceb16914d044c79ad954
diff --git a/a/1.txt b/N2/1.txt index 8e453d6..0a06d33 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,64 +1,74 @@ -T24gV2VkLCAyMDEyLTEwLTI0IGF0IDAxOjQwICswMTAwLCBUaG9tYXMgUmVubmluZ2VyIHdyb3Rl -Ogo+ID4gTW9yZSBhbmQgbW9yZSBvZiBwZW9wbGUgYXJlIGdldHRpbmcgaW50ZXJlc3RlZCBpbiB0 -aGUgc3ViamVjdCBvZiBwb3dlcgo+ID4gKGVuZXJneSkgY29uc3VtcHRpb24gbW9uaXRvcmluZy4g -V2UgaGF2ZSBzb21lIGV4dGVybmFsIHRvb2xzIGxpa2UKPiA+ICJiYXR0ZXJ5IHNpbXVsYXRvcnMi -LCBlbmVyZ3kgcHJvYmVzIGV0Yy4sIGJ1dCBzb21lIHRhcmdldHMgY2FuIG1lYXN1cmUKPiA+IHRo -ZWlyIHBvd2VyIHVzYWdlIG9uIHRoZWlyIG93bi4KPiA+IAo+ID4gVHJhZGl0aW9uYWxseSBzdWNo -IGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIgdmlhIGh3bW9uIHN5c2ZzCj4gPiBp -bnRlcmZhY2UsIGFuZCB0aGF0J3MgZXhhY3RseSB3aGF0IEkgZGlkIGZvciAibXkiIHBsYXRmb3Jt -IC0gSSBoYXZlCj4gPiBhIC9zeXMvY2xhc3MvaHdtb24vaHdtb24qL2RldmljZS9lbmVyZ3kqX2lu -cHV0IGFuZCB0aGlzIHdhcyBnb29kCj4gPiBlbm91Z2ggdG8gZHJhdyBwcmV0dHkgZ3JhcGhzIGlu -IHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4gPiAKPiA+IE5vdyBJIGFtIGdldHRp -bmcgbmV3IHJlcXVlc3RzIHRvIGRvIG1vcmUgd2l0aCB0aGlzIGRhdGEuIEluIHBhcnRpY3VsYXIK -PiA+IEknbSBhc2tlZCBob3cgdG8gYWRkIHN1Y2ggaW5mb3JtYXRpb24gdG8gZnRyYWNlL3BlcmYg -b3V0cHV0Lgo+IFdoeT8gV2hhdCBpcyB0aGUgZ2Fpbj8KPiAKPiBQZXJmIGV2ZW50cyBjYW4gYmUg -dHJpZ2dlcmVkIGF0IGFueSBwb2ludCBpbiB0aGUga2VybmVsLgo+IEEgY3B1ZnJlcSBldmVudCBp -cyB0cmlnZ2VyZWQgd2hlbiB0aGUgZnJlcXVlbmN5IGdldHMgY2hhbmdlZC4KPiBDUFUgaWRsZSBl -dmVudHMgYXJlIHRyaWdnZXJlZCB3aGVuIHRoZSBrZXJuZWwgcmVxdWVzdHMgdG8gZW50ZXIgYW4g -aWRsZSBzdGF0ZQo+IG9yIGV4aXRzIG9uZS4KPiAKPiBXaGVuIHdvdWxkIHlvdSB0cmlnZ2VyIGEg -dGhlcm1hbCBvciBhIHBvd2VyIGV2ZW50Pwo+IFRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0eSBvZiAo -Y3JpdGljYWwpIHRoZXJtYWwgbGltaXRzLgo+IEJ1dCBpZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3Jy -ZWN0bHkgeW91IHdhbnQgdGhpcyBmb3IgZGVidWdnaW5nIGFuZAo+IEkgZ3Vlc3MgeW91IGhhdmUg -ZXZlcnl0aGluZyBpbnRlcmVzdGluZyBvbmUgY2FuIGRvIHdpdGggdGVtcGVyYXR1cmUKPiB2YWx1 -ZXM6Cj4gICAtIHJlYWQgdGhlIHRlbXBlcmF0dXJlCj4gICAtIGRyYXcgc29tZSBuaWNlIGdyYXBo -cyBmcm9tIHRoZSByZXN1bHRzCj4gCj4gSG0sIEkgZ3Vlc3MgSSBrbm93IHdoYXQgeW91IHdhbnQg -dG8gZG86Cj4gSW4geW91ciB0ZW1wZXJhdHVyZS9lbmVyZ3kgZ3JhcGgsIHlvdSB3YW50IHRvIGhh -dmUgc29tZSBkb3RzCj4gd2hlbiByZWxldmFudCBIVyBzdGF0ZXMgKGZyZXF1ZW5jeSwgc2xlZXAg -c3RhdGVzLCAgRERSIHBvd2VyLC4uLikKPiBjaGFuZ2VkLiBUaGVuIHlvdSBhcmUgYWJsZSB0byBz -ZWUgdGhlIGVmZmVjdHMgb3ZlciBhIHRpbWVsaW5lLgo+IAo+IFNvIHlvdSBoYXZlIHRvIGJyaW5n -IHRoZSBleGlzdGluZyBmcmVxdWVuY3kvaWRsZSBwZXJmIGV2ZW50cyB0b2dldGhlcgo+IHdpdGgg -dGVtcGVyYXR1cmUgcmVhZGluZ3MKPiAKPiBDbGVhbmVzdCBzb2x1dGlvbiBjb3VsZCBiZSB0byBl -bmhhbmNlIHRoZSBleGlzaXRpbmcgdXNlcnNwYWNlIGFwcHMKPiAocHl0aW1lY2hhcnQvcGVyZiB0 -aW1lY2hhcnQpIGFuZCBsZXQgdGhlbSBhZGQgYW5vdGhlciBsaW5lCj4gKHRlbXBlcmF0dXJlL2Vu -ZXJneSksIGJ1dCB0aGUgZGF0YSB3b3VsZCBub3QgY29tZSBmcm9tIHBlcmYsIGJ1dAo+IGZyb20g -c3lzZnMvaHdtb24uCj4gTm90IHN1cmUgd2hldGhlciB0aGlzIHdvcmtzIG91dCB3aXRoIHRoZSB0 -aW1lY2hhcnQgdG9vbHMuCj4gQW55d2F5LCB0aGlzIHNvdW5kcyBsaWtlIGEgdXNlcnNwYWNlIG9u -bHkgcHJvYmxlbS4KCk9rLCBzbyBpdCBpcyBhY3R1YWxseSB3aGF0IEknbSB3b3JraW5nIG9uIHJp -Z2h0IG5vdy4gTm90IHdpdGggdGhlCnN0YW5kYXJkIHBlcmYgdG9vbCAodGhlcmUgYXJlIG90aGVy -IHVzZXJzIG9mIHRoYXQgQVBJIDstKSBidXQgaW5kZWVkIEknbQp0cnlpbmcgdG8gImVucmljaCIg -dGhlIGRhdGEgc3RyZWFtIGNvbWluZyBmcm9tIGtlcm5lbCB3aXRoIHVzZXItc3BhY2UKb3JpZ2lu -YXRpbmcgdmFsdWVzLiBJIGFtIGEgbGl0dGxlIGJpdCBjb25jZXJuZWQgYWJvdXQgZWZmZWN0IG9m -IGV4dHJhCnN5c2NhbGxzIChhY2Nlc3NpbmcgdGhlIHZhbHVlIGFuZCBnZXR0aW1lb2ZkYXkgdG8g -Z2VuZXJhdGUgYSB0aW1lc3RhbXApCmF0IGEgaGlnaGVyIHNhbXBsaW5nIHJhdGVzLCBidXQgbW9z -dCBsaWtlbHkgaXQgd29uJ3QgYmUgYSBwcm9ibGVtLiBDYW4KcmVwb3J0IG9uY2UgSSBrbm93IG1v -cmUsIGlmIHRoaXMgaXMgb2YgaW50ZXJlc3QgdG8gYW55b25lLgoKQW55d2F5LCB0aGVyZSBhcmUg -YXQgbGVhc3QgdHdvIGRlYnVnL3RyYWNlIHJlbGF0ZWQgdXNlIGNhc2VzIHRoYXQgY2FuCm5vdCBi -ZSBzYXRpc2ZpZWQgdGhhdCB3YXkgKG9mIGNvdXJzZSBvbmUgY291bGQgYXJndWUgYWJvdXQgdGhl -aXIKdXNlZnVsbmVzcyk6CgoxLiBmdHJhY2Utb3Zlci1uZXR3b3JrIChodHRwczovL2x3bi5uZXQv -QXJ0aWNsZXMvNDEwMjAwLykgd2hpY2ggaXMKcGFydGljdWxhcmx5IGFwcGVhbGluZyBmb3IgImVt -YmVkZGVkIHVzZXJzIiwgd2hlcmUgdGhlcmUncyB2aXJ0dWFsbHkgbm8KdXNlZnVsIHVzZXJzcGFj -ZSBhdmFpbGFibGUgKHRoaW5rIEFuZHJvaWQpLiBIZXJlIGEgKGZ1bmN0aW9uYWwpIHRyYWNlCmV2 -ZW50IGlzIGVtYmVkZGVkIGludG8gYSBub3JtYWwgdHJhY2UgYW5kIGF2YWlsYWJsZSAiZm9yIGZy -ZWUiIGF0IHRoZQpob3N0IHNpZGUuCgoyLiBwZXJmIGdyb3VwcyAtIHRoZSBnZW5lcmFsIGlkZWEg -aXMgdGhhdCBvbmUgZXZlbnQgKGxldCBpdCBiZSBjeWNsZQpjb3VudGVyIGludGVycnVwdCBvciBl -dmVuIGEgdGltZXIpIHRyaWdnZXJzIHJlYWQgb2Ygb3RoZXIgdmFsdWVzIChlZy4KY2FjaGUgY291 -bnRlciBvciAtIGluIHRoaXMgY2FzZSAtIGVuZXJneSBjb3VudGVyKS4gVGhlIGFpbSBpcyB0byBo -YXZlIGEKcmVndWxhciAic25hcHNob3RzIiBvZiB0aGUgc3lzdGVtIHN0YXRlLiBJJ20gbm90IHN1 -cmUgaWYgdGhlIHN0YW5kYXJkCnBlcmYgdG9vbCBjYW4gZG8gdGhpcywgYnV0IEkgZG8gOi0pCgpB -bmQgbGFzdCwgYnV0IG5vdCBsZWFzdCwgdGhlcmUgYXJlIHRoZSBub24tZGVidWcvdHJhY2UgY2xp -ZW50cyBmb3IKZW5lcmd5IGRhdGEgYXMgZGlzY3Vzc2VkIGluIG90aGVyIG1haWxzIGluIHRoaXMg -dGhyZWFkLiBPZiBjb3Vyc2UgdGhlCnRyYWNlIGV2ZW50IHdvbid0IHJlYWxseSBzYXRpc2Z5IHRo -ZWlyIG5lZWRzIGVpdGhlci4KClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjayEKClBhd2XFggoKCgpf -X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3Jz -IG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1z -ZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM +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 usage on their own. +> > +> > 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... +> > +> > 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. +> Why? What is the gain? +> +> Perf events can be triggered at any point in the kernel. +> A cpufreq event is triggered when the frequency gets changed. +> CPU idle events are triggered when the kernel requests to enter an idle state +> or exits one. +> +> When would you trigger a thermal or a power event? +> There is the possibility of (critical) thermal limits. +> But if I understand this correctly you want this for debugging and +> I guess you have everything interesting one can do with temperature +> values: +> - read the temperature +> - draw some nice graphs from the results +> +> Hm, I guess I know what you want to do: +> In your temperature/energy graph, you want to have some dots +> when relevant HW states (frequency, sleep states, DDR power,...) +> changed. Then you are able to see the effects over a timeline. +> +> So you have to bring the existing frequency/idle perf events together +> with temperature readings +> +> Cleanest solution could be to enhance the exisiting userspace apps +> (pytimechart/perf timechart) and let them add another line +> (temperature/energy), but the data would not come from perf, but +> from sysfs/hwmon. +> Not sure whether this works out with the timechart tools. +> Anyway, this sounds like a userspace only problem. + +Ok, so it is actually what I'm working on right now. Not with the +standard perf tool (there are other users of that API ;-) but indeed I'm +trying to "enrich" the data stream coming from kernel with user-space +originating values. I am a little bit concerned about effect of extra +syscalls (accessing the value and gettimeofday to generate a timestamp) +at a higher sampling rates, but most likely it won't be a problem. Can +report once I know more, if this is of interest to anyone. + +Anyway, there are at least two debug/trace related use cases that can +not be satisfied that way (of course one could argue about their +usefulness): + +1. ftrace-over-network (https://lwn.net/Articles/410200/) which is +particularly appealing for "embedded users", where there's virtually no +useful userspace available (think Android). Here a (functional) trace +event is embedded into a normal trace and available "for free" at the +host side. + +2. perf groups - the general idea is that one event (let it be cycle +counter interrupt or even a timer) triggers read of other values (eg. +cache counter or - in this case - energy counter). The aim is to have a +regular "snapshots" of the system state. I'm not sure if the standard +perf tool can do this, but I do :-) + +And last, but not least, there are the non-debug/trace clients for +energy data as discussed in other mails in this thread. Of course the +trace event won't really satisfy their needs either. + +Thanks for your feedback! + +Paweł diff --git a/a/content_digest b/N2/content_digest index 7372eb5..02eb375 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,8 +1,8 @@ "ref\01351013449.9070.5.camel@hornet\0" "ref\04317776.evLpJapyim@hammer82.arch.suse.de\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:51:47 +0000\0" + "Subject\0Re: [RFC] Energy/power monitoring within the kernel\0" + "Date\0Wed, 24 Oct 2012 17:51:47 +0100\0" "To\0Thomas Renninger <trenn@suse.de>\0" "Cc\0Amit Daniel Kachhap <amit.kachhap@linaro.org>" Zhang Rui <rui.zhang@intel.com> @@ -21,69 +21,79 @@ " linaro-dev@lists.linaro.org <linaro-dev@lists.linaro.org>\0" "\00:1\0" "b\0" - "T24gV2VkLCAyMDEyLTEwLTI0IGF0IDAxOjQwICswMTAwLCBUaG9tYXMgUmVubmluZ2VyIHdyb3Rl\n" - "Ogo+ID4gTW9yZSBhbmQgbW9yZSBvZiBwZW9wbGUgYXJlIGdldHRpbmcgaW50ZXJlc3RlZCBpbiB0\n" - "aGUgc3ViamVjdCBvZiBwb3dlcgo+ID4gKGVuZXJneSkgY29uc3VtcHRpb24gbW9uaXRvcmluZy4g\n" - "V2UgaGF2ZSBzb21lIGV4dGVybmFsIHRvb2xzIGxpa2UKPiA+ICJiYXR0ZXJ5IHNpbXVsYXRvcnMi\n" - "LCBlbmVyZ3kgcHJvYmVzIGV0Yy4sIGJ1dCBzb21lIHRhcmdldHMgY2FuIG1lYXN1cmUKPiA+IHRo\n" - "ZWlyIHBvd2VyIHVzYWdlIG9uIHRoZWlyIG93bi4KPiA+IAo+ID4gVHJhZGl0aW9uYWxseSBzdWNo\n" - "IGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIgdmlhIGh3bW9uIHN5c2ZzCj4gPiBp\n" - "bnRlcmZhY2UsIGFuZCB0aGF0J3MgZXhhY3RseSB3aGF0IEkgZGlkIGZvciAibXkiIHBsYXRmb3Jt\n" - "IC0gSSBoYXZlCj4gPiBhIC9zeXMvY2xhc3MvaHdtb24vaHdtb24qL2RldmljZS9lbmVyZ3kqX2lu\n" - "cHV0IGFuZCB0aGlzIHdhcyBnb29kCj4gPiBlbm91Z2ggdG8gZHJhdyBwcmV0dHkgZ3JhcGhzIGlu\n" - "IHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4gPiAKPiA+IE5vdyBJIGFtIGdldHRp\n" - "bmcgbmV3IHJlcXVlc3RzIHRvIGRvIG1vcmUgd2l0aCB0aGlzIGRhdGEuIEluIHBhcnRpY3VsYXIK\n" - "PiA+IEknbSBhc2tlZCBob3cgdG8gYWRkIHN1Y2ggaW5mb3JtYXRpb24gdG8gZnRyYWNlL3BlcmYg\n" - "b3V0cHV0Lgo+IFdoeT8gV2hhdCBpcyB0aGUgZ2Fpbj8KPiAKPiBQZXJmIGV2ZW50cyBjYW4gYmUg\n" - "dHJpZ2dlcmVkIGF0IGFueSBwb2ludCBpbiB0aGUga2VybmVsLgo+IEEgY3B1ZnJlcSBldmVudCBp\n" - "cyB0cmlnZ2VyZWQgd2hlbiB0aGUgZnJlcXVlbmN5IGdldHMgY2hhbmdlZC4KPiBDUFUgaWRsZSBl\n" - "dmVudHMgYXJlIHRyaWdnZXJlZCB3aGVuIHRoZSBrZXJuZWwgcmVxdWVzdHMgdG8gZW50ZXIgYW4g\n" - "aWRsZSBzdGF0ZQo+IG9yIGV4aXRzIG9uZS4KPiAKPiBXaGVuIHdvdWxkIHlvdSB0cmlnZ2VyIGEg\n" - "dGhlcm1hbCBvciBhIHBvd2VyIGV2ZW50Pwo+IFRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0eSBvZiAo\n" - "Y3JpdGljYWwpIHRoZXJtYWwgbGltaXRzLgo+IEJ1dCBpZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3Jy\n" - "ZWN0bHkgeW91IHdhbnQgdGhpcyBmb3IgZGVidWdnaW5nIGFuZAo+IEkgZ3Vlc3MgeW91IGhhdmUg\n" - "ZXZlcnl0aGluZyBpbnRlcmVzdGluZyBvbmUgY2FuIGRvIHdpdGggdGVtcGVyYXR1cmUKPiB2YWx1\n" - "ZXM6Cj4gICAtIHJlYWQgdGhlIHRlbXBlcmF0dXJlCj4gICAtIGRyYXcgc29tZSBuaWNlIGdyYXBo\n" - "cyBmcm9tIHRoZSByZXN1bHRzCj4gCj4gSG0sIEkgZ3Vlc3MgSSBrbm93IHdoYXQgeW91IHdhbnQg\n" - "dG8gZG86Cj4gSW4geW91ciB0ZW1wZXJhdHVyZS9lbmVyZ3kgZ3JhcGgsIHlvdSB3YW50IHRvIGhh\n" - "dmUgc29tZSBkb3RzCj4gd2hlbiByZWxldmFudCBIVyBzdGF0ZXMgKGZyZXF1ZW5jeSwgc2xlZXAg\n" - "c3RhdGVzLCAgRERSIHBvd2VyLC4uLikKPiBjaGFuZ2VkLiBUaGVuIHlvdSBhcmUgYWJsZSB0byBz\n" - "ZWUgdGhlIGVmZmVjdHMgb3ZlciBhIHRpbWVsaW5lLgo+IAo+IFNvIHlvdSBoYXZlIHRvIGJyaW5n\n" - "IHRoZSBleGlzdGluZyBmcmVxdWVuY3kvaWRsZSBwZXJmIGV2ZW50cyB0b2dldGhlcgo+IHdpdGgg\n" - "dGVtcGVyYXR1cmUgcmVhZGluZ3MKPiAKPiBDbGVhbmVzdCBzb2x1dGlvbiBjb3VsZCBiZSB0byBl\n" - "bmhhbmNlIHRoZSBleGlzaXRpbmcgdXNlcnNwYWNlIGFwcHMKPiAocHl0aW1lY2hhcnQvcGVyZiB0\n" - "aW1lY2hhcnQpIGFuZCBsZXQgdGhlbSBhZGQgYW5vdGhlciBsaW5lCj4gKHRlbXBlcmF0dXJlL2Vu\n" - "ZXJneSksIGJ1dCB0aGUgZGF0YSB3b3VsZCBub3QgY29tZSBmcm9tIHBlcmYsIGJ1dAo+IGZyb20g\n" - "c3lzZnMvaHdtb24uCj4gTm90IHN1cmUgd2hldGhlciB0aGlzIHdvcmtzIG91dCB3aXRoIHRoZSB0\n" - "aW1lY2hhcnQgdG9vbHMuCj4gQW55d2F5LCB0aGlzIHNvdW5kcyBsaWtlIGEgdXNlcnNwYWNlIG9u\n" - "bHkgcHJvYmxlbS4KCk9rLCBzbyBpdCBpcyBhY3R1YWxseSB3aGF0IEknbSB3b3JraW5nIG9uIHJp\n" - "Z2h0IG5vdy4gTm90IHdpdGggdGhlCnN0YW5kYXJkIHBlcmYgdG9vbCAodGhlcmUgYXJlIG90aGVy\n" - "IHVzZXJzIG9mIHRoYXQgQVBJIDstKSBidXQgaW5kZWVkIEknbQp0cnlpbmcgdG8gImVucmljaCIg\n" - "dGhlIGRhdGEgc3RyZWFtIGNvbWluZyBmcm9tIGtlcm5lbCB3aXRoIHVzZXItc3BhY2UKb3JpZ2lu\n" - "YXRpbmcgdmFsdWVzLiBJIGFtIGEgbGl0dGxlIGJpdCBjb25jZXJuZWQgYWJvdXQgZWZmZWN0IG9m\n" - "IGV4dHJhCnN5c2NhbGxzIChhY2Nlc3NpbmcgdGhlIHZhbHVlIGFuZCBnZXR0aW1lb2ZkYXkgdG8g\n" - "Z2VuZXJhdGUgYSB0aW1lc3RhbXApCmF0IGEgaGlnaGVyIHNhbXBsaW5nIHJhdGVzLCBidXQgbW9z\n" - "dCBsaWtlbHkgaXQgd29uJ3QgYmUgYSBwcm9ibGVtLiBDYW4KcmVwb3J0IG9uY2UgSSBrbm93IG1v\n" - "cmUsIGlmIHRoaXMgaXMgb2YgaW50ZXJlc3QgdG8gYW55b25lLgoKQW55d2F5LCB0aGVyZSBhcmUg\n" - "YXQgbGVhc3QgdHdvIGRlYnVnL3RyYWNlIHJlbGF0ZWQgdXNlIGNhc2VzIHRoYXQgY2FuCm5vdCBi\n" - "ZSBzYXRpc2ZpZWQgdGhhdCB3YXkgKG9mIGNvdXJzZSBvbmUgY291bGQgYXJndWUgYWJvdXQgdGhl\n" - "aXIKdXNlZnVsbmVzcyk6CgoxLiBmdHJhY2Utb3Zlci1uZXR3b3JrIChodHRwczovL2x3bi5uZXQv\n" - "QXJ0aWNsZXMvNDEwMjAwLykgd2hpY2ggaXMKcGFydGljdWxhcmx5IGFwcGVhbGluZyBmb3IgImVt\n" - "YmVkZGVkIHVzZXJzIiwgd2hlcmUgdGhlcmUncyB2aXJ0dWFsbHkgbm8KdXNlZnVsIHVzZXJzcGFj\n" - "ZSBhdmFpbGFibGUgKHRoaW5rIEFuZHJvaWQpLiBIZXJlIGEgKGZ1bmN0aW9uYWwpIHRyYWNlCmV2\n" - "ZW50IGlzIGVtYmVkZGVkIGludG8gYSBub3JtYWwgdHJhY2UgYW5kIGF2YWlsYWJsZSAiZm9yIGZy\n" - "ZWUiIGF0IHRoZQpob3N0IHNpZGUuCgoyLiBwZXJmIGdyb3VwcyAtIHRoZSBnZW5lcmFsIGlkZWEg\n" - "aXMgdGhhdCBvbmUgZXZlbnQgKGxldCBpdCBiZSBjeWNsZQpjb3VudGVyIGludGVycnVwdCBvciBl\n" - "dmVuIGEgdGltZXIpIHRyaWdnZXJzIHJlYWQgb2Ygb3RoZXIgdmFsdWVzIChlZy4KY2FjaGUgY291\n" - "bnRlciBvciAtIGluIHRoaXMgY2FzZSAtIGVuZXJneSBjb3VudGVyKS4gVGhlIGFpbSBpcyB0byBo\n" - "YXZlIGEKcmVndWxhciAic25hcHNob3RzIiBvZiB0aGUgc3lzdGVtIHN0YXRlLiBJJ20gbm90IHN1\n" - "cmUgaWYgdGhlIHN0YW5kYXJkCnBlcmYgdG9vbCBjYW4gZG8gdGhpcywgYnV0IEkgZG8gOi0pCgpB\n" - "bmQgbGFzdCwgYnV0IG5vdCBsZWFzdCwgdGhlcmUgYXJlIHRoZSBub24tZGVidWcvdHJhY2UgY2xp\n" - "ZW50cyBmb3IKZW5lcmd5IGRhdGEgYXMgZGlzY3Vzc2VkIGluIG90aGVyIG1haWxzIGluIHRoaXMg\n" - "dGhyZWFkLiBPZiBjb3Vyc2UgdGhlCnRyYWNlIGV2ZW50IHdvbid0IHJlYWxseSBzYXRpc2Z5IHRo\n" - "ZWlyIG5lZWRzIGVpdGhlci4KClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjayEKClBhd2XFggoKCgpf\n" - "X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3Jz\n" - "IG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1z\n" - ZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM + "On Wed, 2012-10-24 at 01:40 +0100, Thomas Renninger wrote:\n" + "> > More and more of people are getting interested in the subject of power\n" + "> > (energy) consumption monitoring. We have some external tools like\n" + "> > \"battery simulators\", energy probes etc., but some targets can measure\n" + "> > their power usage on their own.\n" + "> > \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" + "> > 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.\n" + "> Why? What is the gain?\n" + "> \n" + "> Perf events can be triggered at any point in the kernel.\n" + "> A cpufreq event is triggered when the frequency gets changed.\n" + "> CPU idle events are triggered when the kernel requests to enter an idle state\n" + "> or exits one.\n" + "> \n" + "> When would you trigger a thermal or a power event?\n" + "> There is the possibility of (critical) thermal limits.\n" + "> But if I understand this correctly you want this for debugging and\n" + "> I guess you have everything interesting one can do with temperature\n" + "> values:\n" + "> - read the temperature\n" + "> - draw some nice graphs from the results\n" + "> \n" + "> Hm, I guess I know what you want to do:\n" + "> In your temperature/energy graph, you want to have some dots\n" + "> when relevant HW states (frequency, sleep states, DDR power,...)\n" + "> changed. Then you are able to see the effects over a timeline.\n" + "> \n" + "> So you have to bring the existing frequency/idle perf events together\n" + "> with temperature readings\n" + "> \n" + "> Cleanest solution could be to enhance the exisiting userspace apps\n" + "> (pytimechart/perf timechart) and let them add another line\n" + "> (temperature/energy), but the data would not come from perf, but\n" + "> from sysfs/hwmon.\n" + "> Not sure whether this works out with the timechart tools.\n" + "> Anyway, this sounds like a userspace only problem.\n" + "\n" + "Ok, so it is actually what I'm working on right now. Not with the\n" + "standard perf tool (there are other users of that API ;-) but indeed I'm\n" + "trying to \"enrich\" the data stream coming from kernel with user-space\n" + "originating values. I am a little bit concerned about effect of extra\n" + "syscalls (accessing the value and gettimeofday to generate a timestamp)\n" + "at a higher sampling rates, but most likely it won't be a problem. Can\n" + "report once I know more, if this is of interest to anyone.\n" + "\n" + "Anyway, there are at least two debug/trace related use cases that can\n" + "not be satisfied that way (of course one could argue about their\n" + "usefulness):\n" + "\n" + "1. ftrace-over-network (https://lwn.net/Articles/410200/) which is\n" + "particularly appealing for \"embedded users\", where there's virtually no\n" + "useful userspace available (think Android). Here a (functional) trace\n" + "event is embedded into a normal trace and available \"for free\" at the\n" + "host side.\n" + "\n" + "2. perf groups - the general idea is that one event (let it be cycle\n" + "counter interrupt or even a timer) triggers read of other values (eg.\n" + "cache counter or - in this case - energy counter). The aim is to have a\n" + "regular \"snapshots\" of the system state. I'm not sure if the standard\n" + "perf tool can do this, but I do :-)\n" + "\n" + "And last, but not least, there are the non-debug/trace clients for\n" + "energy data as discussed in other mails in this thread. Of course the\n" + "trace event won't really satisfy their needs either.\n" + "\n" + "Thanks for your feedback!\n" + "\n" + "Pawe\305\202" -6f849b5939a10614c0b3bebdc128aac40becd3f1cccd5d86b48f204ba613d6f0 +ee75698cd052b41d8c13030b0d814374f656953f54ba3c8d7de0145daec02f49
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.