diff for duplicates of <5086E6D6.8000208@linaro.org> diff --git a/a/1.txt b/N1/1.txt index eb01584..f51177b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,140 +1,192 @@ -T24gMTAvMjMvMTIgMTk6MzAsIHRoZSBtYWlsIGFwcGFyZW50bHkgZnJvbSBQYXdlbCBNb2xsIGlu -Y2x1ZGVkOgo+IEdyZWV0aW5ncyBBbGwsCj4KPiBNb3JlIGFuZCBtb3JlIG9mIHBlb3BsZSBhcmUg -Z2V0dGluZyBpbnRlcmVzdGVkIGluIHRoZSBzdWJqZWN0IG9mIHBvd2VyCj4gKGVuZXJneSkgY29u -c3VtcHRpb24gbW9uaXRvcmluZy4gV2UgaGF2ZSBzb21lIGV4dGVybmFsIHRvb2xzIGxpa2UKPiAi -YmF0dGVyeSBzaW11bGF0b3JzIiwgZW5lcmd5IHByb2JlcyBldGMuLCBidXQgc29tZSB0YXJnZXRz -IGNhbiBtZWFzdXJlCj4gdGhlaXIgcG93ZXIgdXNhZ2Ugb24gdGhlaXIgb3duLgo+Cj4gVHJhZGl0 -aW9uYWxseSBzdWNoIGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIgdmlhIGh3bW9u -IHN5c2ZzCj4gaW50ZXJmYWNlLCBhbmQgdGhhdCdzIGV4YWN0bHkgd2hhdCBJIGRpZCBmb3IgIm15 -IiBwbGF0Zm9ybSAtIEkgaGF2ZQo+IGEgL3N5cy9jbGFzcy9od21vbi9od21vbiovZGV2aWNlL2Vu -ZXJneSpfaW5wdXQgYW5kIHRoaXMgd2FzIGdvb2QKPiBlbm91Z2ggdG8gZHJhdyBwcmV0dHkgZ3Jh -cGhzIGluIHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4KPiBOb3cgSSBhbSBnZXR0 -aW5nIG5ldyByZXF1ZXN0cyB0byBkbyBtb3JlIHdpdGggdGhpcyBkYXRhLiBJbiBwYXJ0aWN1bGFy -Cj4gSSdtIGFza2VkIGhvdyB0byBhZGQgc3VjaCBpbmZvcm1hdGlvbiB0byBmdHJhY2UvcGVyZiBv -dXRwdXQuIFRoZSBzZWNvbmQKPiBtb3N0IGZyZXF1ZW50IHJlcXVlc3QgaXMgYWJvdXQgcHJvdmlk -aW5nIGl0IHRvIGEgImVuZXJneSBhd2FyZSIKPiBjcHVmcmVxIGdvdmVybm9yLgo+Cj4gSSd2ZSBj -YW1lIHVwIHdpdGggdGhyZWUgKG5vbi1tdXR1YWxseSBleGNsdXNpdmUpIG9wdGlvbnMuIEkgd2ls -bAo+IGFwcHJlY2lhdGUgYW55IG90aGVyIGlkZWFzIGFuZCBjb21tZW50cyAoaW5jbHVkaW5nICJp -dCBtYWtlcyBub3Qgc2Vuc2UKPiB3aGF0c29ldmVyIiBvbmVzLCB3aXRoIGp1c3RpZmljYXRpb24p -LiBPZiBjb3Vyc2UgSSBhbSBtb3JlIHRoYW4gd2lsbGluZwo+IHRvIHNwZW5kIHRpbWUgb24gcHJv -dG90eXBpbmcgYW55dGhpbmcgdGhhdCBzZWVtcyByZWFzb25hYmxlIGFuZCBwcm9wb3NlCj4gcGF0 -Y2hlcy4KPgo+Cj4KPiA9PT0gT3B0aW9uIDE6IFRyYWNlIGV2ZW50ID09PQo+Cj4gVGhpcyBzZWVt -cyB0byBiZSB0aGUgImNoZWFwZXN0IiBvcHRpb24uIFNpbXBseSBkZWZpbmluZyBhIHRyYWNlIGV2 -ZW50Cj4gdGhhdCBjYW4gYmUgZ2VuZXJhdGVkIGJ5IGEgaHdtb24gKG9yIGFueSBvdGhlcikgZHJp -dmVyIG1ha2VzIHRoZQo+IGludGVyZXN0aW5nIGRhdGEgaW1tZWRpYXRlbHkgYXZhaWxhYmxlIHRv -IGFueSBmdHJhY2UvcGVyZiB1c2VyLiBPZgo+IGNvdXJzZSBpdCBkb2Vzbid0IHJlYWxseSBoZWxw -IHdpdGggdGhlIGNwdWZyZXEgY2FzZSwgYnV0IHNlZW1zIHRvIGJlCj4gYSBnb29kIHBsYWNlIHRv -IHN0YXJ0IHdpdGguCj4KPiBUaGUgcXVlc3Rpb24gaXMgaG93IHRvIGRlZmluZSBpdC4uLiBJJ3Zl -IGNhbWUgdXAgd2l0aCB0d28gcHJvdG90eXBlczoKPgo+ID0gR2VuZXJpYyBod21vbiB0cmFjZSBl -dmVudCA9Cj4KPiBUaGlzIG9uZSBhbGxvd3MgYW55IGRyaXZlciB0byBnZW5lcmF0ZSBhIHRyYWNl -IGV2ZW50IHdoZW5ldmVyIGFueQo+ICJod21vbiBhdHRyaWJ1dGUiIChtZWFzdXJlZCB2YWx1ZSkg -Z2V0cyB1cGRhdGVkLiBUaGUgcmF0ZSBhdCB3aGljaCB0aGUKPiB1cGRhdGVzIGhhcHBlbiBjYW4g -YmUgY29udHJvbGxlZCBieSBhbHJlYWR5IGV4aXN0aW5nICJ1cGRhdGVfaW50ZXJ2YWwiCj4gYXR0 -cmlidXRlLgo+Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t -Cj4gVFJBQ0VfRVZFTlQoaHdtb25fYXR0cl91cGRhdGUsCj4gCVRQX1BST1RPKHN0cnVjdCBkZXZp -Y2UgKmRldiwgc3RydWN0IGF0dHJpYnV0ZSAqYXR0ciwgbG9uZyBsb25nIGlucHV0KSwKPiAJVFBf -QVJHUyhkZXYsIGF0dHIsIGlucHV0KSwKPgo+IAlUUF9TVFJVQ1RfX2VudHJ5KAo+IAkJX19zdHJp -bmcoICAgICAgIGRldiwJCWRldl9uYW1lKGRldikpCj4gCQlfX3N0cmluZygJYXR0ciwJCWF0dHIt -Pm5hbWUpCj4gCQlfX2ZpZWxkKAlsb25nIGxvbmcsCWlucHV0KQo+IAkpLAo+Cj4gCVRQX2Zhc3Rf -YXNzaWduKAo+IAkJX19hc3NpZ25fc3RyKGRldiwgZGV2X25hbWUoZGV2KSk7Cj4gCQlfX2Fzc2ln -bl9zdHIoYXR0ciwgYXR0ci0+bmFtZSk7Cj4gCQlfX2VudHJ5LT5pbnB1dCA9IGlucHV0Owo+IAkp -LAo+Cj4gCVRQX3ByaW50aygiJXMgJXMgJWxsZCIsIF9fZ2V0X3N0cihkZXYpLCBfX2dldF9zdHIo -YXR0ciksIF9fZW50cnktPmlucHV0KQo+ICk7Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t -LS0tLS0tLS0tLS0tLS0tLS0tCj4KPiBJdCBnZW5lcmF0ZXMgc3VjaCBmdHJhY2UgbWVzc2FnZToK -Pgo+IDwuLi4+MjEyLjY3MzEyNjogaHdtb25fYXR0cl91cGRhdGU6IGh3bW9uNCB0ZW1wMV9pbnB1 -dCAzNDM2MQo+Cj4gT25lIGlzc3VlIHdpdGggdGhpcyBpcyB0aGF0IHNvbWUgZXh0ZXJuYWwga25v -d2xlZGdlIGlzIHJlcXVpcmVkIHRvCj4gcmVsYXRlIGEgbnVtYmVyIHRvIGEgcHJvY2Vzc29yIGNv -cmUuIE9yIG1heWJlIGl0J3Mgbm90IGFuIGlzc3VlIGF0IGFsbAo+IGJlY2F1c2UgaXQgc2hvdWxk -IGJlIGxlZnQgZm9yIHRoZSB1c2VyKHNwYWNlKT8KPgo+ID0gQ1BVIHBvd2VyL2VuZXJneS90ZW1w -ZXJhdHVyZSB0cmFjZSBldmVudCA9Cj4KPiBUaGlzIG9uZSBpcyBkZXNpZ25lZCB0byBlbXBoYXNp -emUgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIG1lYXN1cmVkCj4gdmFsdWUgKHdoZXRoZXIgaXQg -aXMgZW5lcmd5LCB0ZW1wZXJhdHVyZSBvciBhbnkgb3RoZXIgcGh5c2ljYWwKPiBwaGVub21lbmEs -IHJlYWxseSkgYW5kIENQVXMsIHNvIGl0IGlzIHF1aXRlIHNwZWNpZmljICh0b28gc3BlY2lmaWM/ -KQo+Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVFJB -Q0VfRVZFTlQoY3B1c19lbnZpcm9ubWVudCwKPiAJVFBfUFJPVE8oY29uc3Qgc3RydWN0IGNwdW1h -c2sgKmNwdXMsIGxvbmcgbG9uZyB2YWx1ZSwgY2hhciB1bml0KSwKPiAJVFBfQVJHUyhjcHVzLCB2 -YWx1ZSwgdW5pdCksCj4KPiAJVFBfU1RSVUNUX19lbnRyeSgKPiAJCV9fYXJyYXkoCXVuc2lnbmVk -IGNoYXIsCWNwdXMsCXNpemVvZihzdHJ1Y3QgY3B1bWFzaykpCj4gCQlfX2ZpZWxkKAlsb25nIGxv -bmcsCXZhbHVlKQo+IAkJX19maWVsZCgJY2hhciwJCXVuaXQpCj4gCSksCj4KPiAJVFBfZmFzdF9h -c3NpZ24oCj4gCQltZW1jcHkoX19lbnRyeS0+Y3B1cywgY3B1cywgc2l6ZW9mKHN0cnVjdCBjcHVt -YXNrKSk7Cj4gCQlfX2VudHJ5LT52YWx1ZSA9IHZhbHVlOwo+IAkJX19lbnRyeS0+dW5pdCA9IHVu -aXQ7Cj4gCSksCj4KPiAJVFBfcHJpbnRrKCJjcHVzICVzICVsbGRbJWNdIiwKPiAJCV9fcHJpbnRf -Y3B1bWFzaygoc3RydWN0IGNwdW1hc2sgKilfX2VudHJ5LT5jcHVzKSwKPiAJCV9fZW50cnktPnZh -bHVlLCBfX2VudHJ5LT51bml0KQo+ICk7Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t -LS0tLS0tLS0tLS0tLS0tCj4KPiBBbmQgdGhlIGVxdWl2YWxlbnQgZnRyYWNlIG1lc3NhZ2UgaXM6 -Cj4KPiA8Li4uPjEyNy4wNjMxMDc6IGNwdXNfZW52aXJvbm1lbnQ6IGNwdXMgMCwxLDIsMyAzNDM2 -MVtDXQo+Cj4gSXQncyBhIGNwdW1hc2ssIG5vdCBqdXN0IHNpbmdsZSBjcHUgaWQsIGJlY2F1c2Ug -dGhlIHNlbnNvciBtYXkgbWVhc3VyZQo+IHRoZSB2YWx1ZSBwZXIgc2V0IG9mIENQVXMsIGVnLiBh -IHRlbXBlcmF0dXJlIG9mIHRoZSB3aG9sZSBzaWxpY29uIGRpZQo+IChzbyBhbGwgdGhlIGNvcmVz -KSBvciBhbiBlbmVyZ3kgY29uc3VtZWQgYnkgYSBzdWJzZXQgb2YgY29yZXMgKHRoaXMKPiBpcyBt -eSBwYXJ0aWN1bGFyIHVzZSBjYXNlIC0gdHdvIG1ldGVycyBtb25pdG9yIGEgY2x1c3RlciBvZiB0 -d28KPiBwcm9jZXNzb3JzIGFuZCBhIGNsdXN0ZXIgb2YgdGhyZWUgcHJvY2Vzc29ycywgYWxsIHdv -cmtpbmcgYXMgYSBTTVAKPiBzeXN0ZW0pLgo+Cj4gT2YgY291cnNlIHRoZSBjcHVzIF9fYXJyYXkg -Y291bGQgYmUgYWN0dWFsbHkgYSBzcGVjaWFsIF9fY3B1bWFzayBmaWVsZAo+IHR5cGUgKEkndmUg -anVzdCBoYWNrZWQgdGhlIF9fcHJpbnRfY3B1bWFzayBzbyBmYXIpLiBBbmQgSSd2ZSBqdXN0Cj4g -cmVhbGlzZWQgdGhhdCB0aGUgdW5pdCBmaWVsZCBzaG91bGQgYWN0dWFsbHkgYmUgYSBzdHJpbmcg -dG8gYWxsb3cgdW5pdAo+IHByZWZpeGVzIHRvIGJlIHNwZWNpZmllZCAodGhlIGFib3ZlIHNob3Vs -ZCBvYnZpb3VzbHkgYmUgIjM0MzYxW21DXSIKPiBub3QgIltDXSIpLiBBbHNvIC0gZXhjdXNlIHRo -ZSAiY3B1c19lbnZpcm9ubWVudCIgbmFtZSAtIHRoaXMgd2FzIHRoZQo+IGJlc3QgSSB3YXMgYWJs -ZSB0byBjb21lIHVwIHdpdGggYXQgdGhlIHRpbWUgYW5kIEknbSBlYWdlciB0byBhY2NlcHQKPiBh -bnkgYWx0ZXJuYXRpdmUgc3VnZ2VzdGlvbnMgOi0pCgpBIHRob3VnaHQgb24gdGhhdC4uLiBmcm9t -IGFuIFNvQyBwZXJzcGVjdGl2ZSB0aGVyZSBhcmUgb3RoZXIgaW50ZXJlc3RpbmcgCnBvd2VyIHJh -aWxzIHRoYW4gZ28gdG8ganVzdCB0aGUgQ1BVIGNvcmUuICBGb3IgZXhhbXBsZSBERFIgcG93ZXIg -YW5kIApyYWlscyBpbnZvbHZlZCB3aXRoIG90aGVyIElQIHVuaXRzIG9uIHRoZSBTb0Mgc3VjaCBh -cyAzRCBncmFwaGljcyB1bml0LiAKICBTbyB0eWluZyBvbmUgbnVtYmVyIHRvIHNwZWNpZmljYWxs -eSBhIENQVSBjb3JlIGRvZXMgbm90IHNvdW5kIGxpa2UgCml0J3MgZW5vdWdoLgoKPiA9PT0gT3B0 -aW9uIDI6IGh3bW9uIHBlcmYgUE1VID09PQo+Cj4gQWx0aG91Z2ggdGhlIHRyYWNlIGV2ZW50IG1h -a2VzIGl0IHBvc3NpYmxlIHRvIG9idGFpbiBpbnRlcmVzdGluZwo+IGluZm9ybWF0aW9uIHVzaW5n -IHBlcmYsIHRoZSB1c2VyIHdvdWxkbid0IGJlIGFibGUgdG8gdHJlYXQgdGhlCj4gZW5lcmd5IG1l -dGVyIGFzIGEgbm9ybWFsIGRhdGEgc291cmNlLiBJbiBwYXJ0aWN1bGFyIHRoZXJlIHdvdWxkCj4g -YmUgbm8gd2F5IG9mIGNyZWF0aW5nIGEgZ3JvdXAgb2YgZXZlbnRzIGNvbnNpc3RpbmcgZWcuIG9m -IGEKPiAibm9ybWFsIiBsZWFkZXIgKGVnLiBjYWNoZSBtaXNzIGV2ZW50KSB0cmlnZ2VyaW5nIGVu -ZXJneSBtZXRlcgo+IHJlYWQuIFRoZSBvbmx5IHdheSB0byBnZXQgdGhpcyBkb25lIGlzIHRvIGlt -cGxlbWVudCBhIHBlcmYgUE1VCj4gYmFja2VuZCBwcm92aWRpbmcgImVudmlyb25tZW50YWwgZGF0 -YSIgdG8gdGhlIHVzZXIuCgpJbiB0ZXJtcyBvZiBsaWtlIHBlcmYgdG9wIGRvbid0IHRoaW5rIGl0 -J2xsIGJlIHBvc3NpYmxlIHRvIGtub3cgd2hlbiB0byAKc2FtcGxlIHRoZSBhY3F1aXNpdGlvbiBo -YXJkd2FyZSB0byB0aWUgdGhlIHJlc3VsdCB0byBhIHBhcnRpY3VsYXIgbGluZSAKb2YgY29kZSwg -ZXZlbiBpZiBpdCBoYWQgdGhlIGJhbmR3aWR0aCB0byBkbyB0aGF0LiAgUG93ZXIgcmVhZGluZ3Mg -YXJlIApsaWtlbHkgdG8gbGFnIGFjdGl2aXRpZXMgb24gdGhlIGNwdSBzb21ld2hhdCwgY29uc2lk -ZXJpbmcgc3ViLW5zIGNvcmUgCmNsb2NrcywgZXNwZWNpYWxseSBpZiBpdCdzIGFjdHVhbGx5IG1l -YXN1cmluZyB0aGUgaW5wdXQgc2lkZSBvZiBhIHJlZ3VsYXRvci4KCj4gPSBIaWdoLWxldmVsIGh3 -bW9uIEFQSSBhbmQgUE1VID0KPgo+IEN1cnJlbnQgaHdtb24gc3Vic3lzdGVtIGRvZXMgbm90IHBy -b3ZpZGUgYW55IGFic3RyYWN0aW9uIGZvciB0aGUKPiBtZWFzdXJlZCB2YWx1ZXMgYW5kIHJlcXVp -cmVzIHBhcnRpY3VsYXIgZHJpdmVycyB0byBjcmVhdGUgc3BlY2lmaWVkCj4gc3lzZnMgYXR0cmli -dXRlcyB0aGFuIHVzZWQgYnkgdXNlcnNwYWNlIGxpYnNlbnNvcnMuIFRoaXMgbWFrZXMKPiB0aGUg -ZnJhbWV3b3JrIHVsdGltYXRlbHkgZmxleGlibGUgYW5kIHVsdGltYXRlbHkgaGFyZCB0byBhY2Nl -c3MKPiBmcm9tIHdpdGhpbiB0aGUga2VybmVsLi4uCj4KPiBXaGF0IGNvdWxkIGJlIGRvbmUgaGVy -ZSBpcyBzb21lIChzaW1wbGUpIEFQSSB0byByZWdpc3RlciB0aGUKPiBtZWFzdXJlZCB2YWx1ZXMg -d2l0aCB0aGUgaHdtb24gY29yZSB3aGljaCB3b3VsZCByZXN1bHQgaW4gY3JlYXRpbmcKPiBlcXVp -dmFsZW50IHN5c2ZzIGF0dHJpYnV0ZXMgYXV0b21hZ2ljYWxseSwgYnV0IGFsc28gYWxsb3cgYQo+ -IGluLWtlcm5lbCBBUEkgZm9yIHZhbHVlcyBlbnVtZXJhdGlvbiBhbmQgYWNjZXNzLiBUaGF0IHdh -eSB0aGUgY29yZQo+IGNvdWxkIGFsc28gcmVnaXN0ZXIgYSAiaHdtb24gUE1VIiB3aXRoIHRoZSBw -ZXJmIGZyYW1ld29yayBwcm92aWRpbmcKPiBkYXRhIGZyb20gYWxsICJjb21wbGlhbnQiIGRyaXZl -cnMuCj4KPiA9IEEgZHJpdmVyLXNwZWNpZmljIFBNVSA9Cj4KPiBPZiBjb3Vyc2UgYSBwYXJ0aWN1 -bGFyIGRyaXZlciBjb3VsZCByZWdpc3RlciBpdHMgb3duIHBlcmYgUE1VIG9uIGl0cwo+IG93bi4g -SXQncyBjZXJ0YWlubHkgYW4gb3B0aW9uLCBqdXN0IHZlcnkgc3Vib3B0aW1hbCBpbiBteSBvcGlu -aW9uLgo+IE9yIG1heWJlIG5vdD8gTWF5YmUgdGhlIHRhc2sgaXMgc28gc3BlY2lhbGl6ZWQgdGhh -dCBpdCBtYWtlcyBzZW5zZT8KPgo+Cj4KPiA9PT0gT3B0aW9uIDM6IENQVSBwb3dlcihlbmVyZ3kp -IG1vbml0b3JpbmcgZnJhbWV3b3JrID09PQo+Cj4gQW5kIGxhc3QgYnV0IG5vdCBsZWFzdCwgbWF5 -YmUgdGhlIHByb2JsZW0gZGVzZXJ2ZXMgc29tZSBkZWRpY2F0ZWQKPiBBUEk/IFNvbWV0aGluZyB0 -aGF0IHdvdWxkIHRha2UgcHJvdmlkZXJzIGFuZCBmZWVkIHRoZWlyIGRhdGEgaW50bwo+IGludGVy -ZXN0ZWQgcGFydGllcywgaW4gcGFydGljdWxhciBhIHBlcmYgUE1VIGltcGxlbWVudGF0aW9uIGFu -ZAo+IGNwdWZyZXEgZ292ZXJub3JzPwo+Cj4gTWF5YmUgaXQgY291bGQgYmUgYW4gZXh0ZW5zaW9u -IHRvIHRoZSB0aGVybWFsIGZyYW1ld29yaz8gSXQgYWxyZWFkeQo+IGdpdmVzIHNvbWUgbWVhbmlu -ZyB0byBhIHBoeXNpY2FsIHBoZW5vbWVuYS4gQWRkaW5nIG90aGVyLCByZWxhdGVkIG9uZXMKPiBs -aWtlIGVuZXJneSwgYW5kIHJlbGF0aW5nIGl0IHRvIGNwdSBjb3JlcyBjb3VsZCBtYWtlIHNvbWUg -c2Vuc2UuCgpJZiB5b3UgdHVybiB0aGUgcHJvYmxlbSB1cHNpZGUgZG93biB0byBzb2x2ZSB0aGUg -cmVwcmVzZW50YXRpb24gcXVlc3Rpb24gCmZpcnN0LCBtYXliZSB0aGVyZSdzIGEgd2F5IGZvcndh -cmQgZGVmaW5pbmcgdGhlICJwb3dlciB0cmVlIiBpbiB0ZXJtcyBvZiAKcmVndWxhdG9ycywgYW5k -IHRoZW4gYWRkaW5nIHNvbWV0aGluZyBpbiBzdHJ1Y3QgcmVndWxhdG9yIHRoYXQgc3BhbXMgCnJl -YWRlcnMgd2l0aCB0aW1lc3RhbXBlZCByZXN1bHRzIGlmIHRoZSByZWd1bGF0b3IgaGFzIGEgcG93 -ZXIgbW9uaXRvcmluZyAKY2FwYWJpbGl0eS4KClRoZW4geW91IGNhbiBtYXAgdGhlIHJlZ3VsYXRv -cnMgaW4gdGhlIHBvd2VyIHRyZWUgdG8gcmVhbCBkZXZpY2VzIGJ5IHRoZSAKbmFtZXMgb3IgdGhl -IHN1cHBseSBzdHVmZi4gIEp1c3QgYSB0aG91Z2h0LgoKLUFuZHkKCi0tIApBbmR5IEdyZWVuIHwg -VEkgTGFuZGluZyBUZWFtIExlYWRlcgpMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2Fy -ZSBmb3IgQVJNIFNvQ3MgfCBGb2xsb3cgTGluYXJvCmh0dHA6Ly9mYWNlYm9vay5jb20vcGFnZXMv -TGluYXJvLzE1NTk3NDU4MTA5MTEwNiAgLSAKaHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFyb29y -ZyAtIGh0dHA6Ly9saW5hcm8ub3JnL2xpbmFyby1ibG9nCgpfX19fX19fX19fX19fX19fX19fX19f -X19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5z -b3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xp -c3RpbmZvL2xtLXNlbnNvcnM +On 10/23/12 19:30, the mail apparently from Pawel Moll included: +> Greetings All, +> +> More and more of people are getting interested in the subject of power +> (energy) consumption monitoring. We have some external tools like +> "battery simulators", energy probes etc., but some targets can measure +> their 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. The second +> most frequent request is about providing it to a "energy aware" +> cpufreq governor. +> +> I've came up with three (non-mutually exclusive) options. I will +> appreciate any other ideas and comments (including "it makes not sense +> whatsoever" ones, with justification). Of course I am more than willing +> to spend time on prototyping anything that seems reasonable and propose +> patches. +> +> +> +> === Option 1: Trace event === +> +> This seems to be the "cheapest" option. Simply defining a trace event +> that can be generated by a hwmon (or any other) driver makes the +> interesting data immediately available to any ftrace/perf user. Of +> course it doesn't really help with the cpufreq case, but seems to be +> a good place to start with. +> +> The question is how to define it... I've came up with two prototypes: +> +> = Generic hwmon trace event = +> +> This one allows any driver to generate a trace event whenever any +> "hwmon attribute" (measured value) gets updated. The rate at which the +> updates happen can be controlled by already existing "update_interval" +> attribute. +> +> 8<------------------------------------------- +> TRACE_EVENT(hwmon_attr_update, +> TP_PROTO(struct device *dev, struct attribute *attr, long long input), +> TP_ARGS(dev, attr, input), +> +> TP_STRUCT__entry( +> __string( dev, dev_name(dev)) +> __string( attr, attr->name) +> __field( long long, input) +> ), +> +> TP_fast_assign( +> __assign_str(dev, dev_name(dev)); +> __assign_str(attr, attr->name); +> __entry->input = input; +> ), +> +> TP_printk("%s %s %lld", __get_str(dev), __get_str(attr), __entry->input) +> ); +> 8<------------------------------------------- +> +> It generates such ftrace message: +> +> <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361 +> +> One issue with this is that some external knowledge is required to +> relate a number to a processor core. Or maybe it's not an issue at all +> because it should be left for the user(space)? +> +> = CPU power/energy/temperature trace event = +> +> This one is designed to emphasize the relation between the measured +> value (whether it is energy, temperature or any other physical +> phenomena, really) and CPUs, so it is quite specific (too specific?) +> +> 8<------------------------------------------- +> TRACE_EVENT(cpus_environment, +> TP_PROTO(const struct cpumask *cpus, long long value, char unit), +> TP_ARGS(cpus, value, unit), +> +> TP_STRUCT__entry( +> __array( unsigned char, cpus, sizeof(struct cpumask)) +> __field( long long, value) +> __field( char, unit) +> ), +> +> TP_fast_assign( +> memcpy(__entry->cpus, cpus, sizeof(struct cpumask)); +> __entry->value = value; +> __entry->unit = unit; +> ), +> +> TP_printk("cpus %s %lld[%c]", +> __print_cpumask((struct cpumask *)__entry->cpus), +> __entry->value, __entry->unit) +> ); +> 8<------------------------------------------- +> +> And the equivalent ftrace message is: +> +> <...>127.063107: cpus_environment: cpus 0,1,2,3 34361[C] +> +> It's a cpumask, not just single cpu id, because the sensor may measure +> the value per set of CPUs, eg. a temperature of the whole silicon die +> (so all the cores) or an energy consumed by a subset of cores (this +> is my particular use case - two meters monitor a cluster of two +> processors and a cluster of three processors, all working as a SMP +> system). +> +> Of course the cpus __array could be actually a special __cpumask field +> type (I've just hacked the __print_cpumask so far). And I've just +> realised that the unit field should actually be a string to allow unit +> prefixes to be specified (the above should obviously be "34361[mC]" +> not "[C]"). Also - excuse the "cpus_environment" name - this was the +> best I was able to come up with at the time and I'm eager to accept +> any alternative suggestions :-) + +A thought on that... from an SoC perspective there are other interesting +power rails than go to just the CPU core. For example DDR power and +rails involved with other IP units on the SoC such as 3D graphics unit. + So tying one number to specifically a CPU core does not sound like +it's enough. + +> === Option 2: hwmon perf PMU === +> +> Although the trace event makes it possible to obtain interesting +> information using perf, the user wouldn't be able to treat the +> energy meter as a normal data source. In particular there would +> be no way of creating a group of events consisting eg. of a +> "normal" leader (eg. cache miss event) triggering energy meter +> read. The only way to get this done is to implement a perf PMU +> backend providing "environmental data" to the user. + +In terms of like perf top don't think it'll be possible to know when to +sample the acquisition hardware to tie the result to a particular line +of code, even if it had the bandwidth to do that. Power readings are +likely to lag activities on the cpu somewhat, considering sub-ns core +clocks, especially if it's actually measuring the input side of a regulator. + +> = High-level hwmon API and PMU = +> +> Current hwmon subsystem does not provide any abstraction for the +> measured values and requires particular drivers to create specified +> sysfs attributes than used by userspace libsensors. This makes +> the framework ultimately flexible and ultimately hard to access +> from within the kernel... +> +> What could be done here is some (simple) API to register the +> measured values with the hwmon core which would result in creating +> equivalent sysfs attributes automagically, but also allow a +> in-kernel API for values enumeration and access. That way the core +> could also register a "hwmon PMU" with the perf framework providing +> data from all "compliant" drivers. +> +> = A driver-specific PMU = +> +> 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? +> +> +> +> === Option 3: CPU power(energy) monitoring framework === +> +> And last but not least, maybe the problem deserves some dedicated +> API? Something that would take providers and feed their data into +> interested parties, in particular a perf PMU implementation and +> cpufreq governors? +> +> Maybe it could be an extension to the thermal framework? It already +> gives some meaning to a physical phenomena. Adding other, related ones +> like energy, and relating it to cpu cores could make some sense. + +If you turn the problem upside down to solve the representation question +first, maybe there's a way forward defining the "power tree" in terms of +regulators, and then adding something in struct regulator that spams +readers with timestamped results if the regulator has a power monitoring +capability. + +Then you can map the regulators in the power tree to real devices by the +names or the supply stuff. Just a thought. + +-Andy + +-- +Andy Green | TI Landing Team Leader +Linaro.org ? Open source software for ARM SoCs | Follow Linaro +http://facebook.com/pages/Linaro/155974581091106 - +http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog diff --git a/a/content_digest b/N1/content_digest index 6ff97b4..6c648e9 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,165 +1,201 @@ "ref\01351013449.9070.5.camel@hornet\0" - "From\0Andy Green <andy.green@linaro.org>\0" - "Subject\0Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel\0" - "Date\0Tue, 23 Oct 2012 18:49:58 +0000\0" - "To\0Pawel Moll <pawel.moll@arm.com>\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> - Thomas Renninger <trenn@suse.de> - Jean Pihet <jean.pihet@newoldbits.com> - linaro-dev@lists.linaro.org - linux-kernel@vger.kernel.org - linux-arm-kernel@lists.infradead.org - " lm-sensors@lm-sensors.org\0" + "From\0andy.green@linaro.org (Andy Green)\0" + "Subject\0[RFC] Energy/power monitoring within the kernel\0" + "Date\0Tue, 23 Oct 2012 20:49:58 +0200\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" - "T24gMTAvMjMvMTIgMTk6MzAsIHRoZSBtYWlsIGFwcGFyZW50bHkgZnJvbSBQYXdlbCBNb2xsIGlu\n" - "Y2x1ZGVkOgo+IEdyZWV0aW5ncyBBbGwsCj4KPiBNb3JlIGFuZCBtb3JlIG9mIHBlb3BsZSBhcmUg\n" - "Z2V0dGluZyBpbnRlcmVzdGVkIGluIHRoZSBzdWJqZWN0IG9mIHBvd2VyCj4gKGVuZXJneSkgY29u\n" - "c3VtcHRpb24gbW9uaXRvcmluZy4gV2UgaGF2ZSBzb21lIGV4dGVybmFsIHRvb2xzIGxpa2UKPiAi\n" - "YmF0dGVyeSBzaW11bGF0b3JzIiwgZW5lcmd5IHByb2JlcyBldGMuLCBidXQgc29tZSB0YXJnZXRz\n" - "IGNhbiBtZWFzdXJlCj4gdGhlaXIgcG93ZXIgdXNhZ2Ugb24gdGhlaXIgb3duLgo+Cj4gVHJhZGl0\n" - "aW9uYWxseSBzdWNoIGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIgdmlhIGh3bW9u\n" - "IHN5c2ZzCj4gaW50ZXJmYWNlLCBhbmQgdGhhdCdzIGV4YWN0bHkgd2hhdCBJIGRpZCBmb3IgIm15\n" - "IiBwbGF0Zm9ybSAtIEkgaGF2ZQo+IGEgL3N5cy9jbGFzcy9od21vbi9od21vbiovZGV2aWNlL2Vu\n" - "ZXJneSpfaW5wdXQgYW5kIHRoaXMgd2FzIGdvb2QKPiBlbm91Z2ggdG8gZHJhdyBwcmV0dHkgZ3Jh\n" - "cGhzIGluIHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4KPiBOb3cgSSBhbSBnZXR0\n" - "aW5nIG5ldyByZXF1ZXN0cyB0byBkbyBtb3JlIHdpdGggdGhpcyBkYXRhLiBJbiBwYXJ0aWN1bGFy\n" - "Cj4gSSdtIGFza2VkIGhvdyB0byBhZGQgc3VjaCBpbmZvcm1hdGlvbiB0byBmdHJhY2UvcGVyZiBv\n" - "dXRwdXQuIFRoZSBzZWNvbmQKPiBtb3N0IGZyZXF1ZW50IHJlcXVlc3QgaXMgYWJvdXQgcHJvdmlk\n" - "aW5nIGl0IHRvIGEgImVuZXJneSBhd2FyZSIKPiBjcHVmcmVxIGdvdmVybm9yLgo+Cj4gSSd2ZSBj\n" - "YW1lIHVwIHdpdGggdGhyZWUgKG5vbi1tdXR1YWxseSBleGNsdXNpdmUpIG9wdGlvbnMuIEkgd2ls\n" - "bAo+IGFwcHJlY2lhdGUgYW55IG90aGVyIGlkZWFzIGFuZCBjb21tZW50cyAoaW5jbHVkaW5nICJp\n" - "dCBtYWtlcyBub3Qgc2Vuc2UKPiB3aGF0c29ldmVyIiBvbmVzLCB3aXRoIGp1c3RpZmljYXRpb24p\n" - "LiBPZiBjb3Vyc2UgSSBhbSBtb3JlIHRoYW4gd2lsbGluZwo+IHRvIHNwZW5kIHRpbWUgb24gcHJv\n" - "dG90eXBpbmcgYW55dGhpbmcgdGhhdCBzZWVtcyByZWFzb25hYmxlIGFuZCBwcm9wb3NlCj4gcGF0\n" - "Y2hlcy4KPgo+Cj4KPiA9PT0gT3B0aW9uIDE6IFRyYWNlIGV2ZW50ID09PQo+Cj4gVGhpcyBzZWVt\n" - "cyB0byBiZSB0aGUgImNoZWFwZXN0IiBvcHRpb24uIFNpbXBseSBkZWZpbmluZyBhIHRyYWNlIGV2\n" - "ZW50Cj4gdGhhdCBjYW4gYmUgZ2VuZXJhdGVkIGJ5IGEgaHdtb24gKG9yIGFueSBvdGhlcikgZHJp\n" - "dmVyIG1ha2VzIHRoZQo+IGludGVyZXN0aW5nIGRhdGEgaW1tZWRpYXRlbHkgYXZhaWxhYmxlIHRv\n" - "IGFueSBmdHJhY2UvcGVyZiB1c2VyLiBPZgo+IGNvdXJzZSBpdCBkb2Vzbid0IHJlYWxseSBoZWxw\n" - "IHdpdGggdGhlIGNwdWZyZXEgY2FzZSwgYnV0IHNlZW1zIHRvIGJlCj4gYSBnb29kIHBsYWNlIHRv\n" - "IHN0YXJ0IHdpdGguCj4KPiBUaGUgcXVlc3Rpb24gaXMgaG93IHRvIGRlZmluZSBpdC4uLiBJJ3Zl\n" - "IGNhbWUgdXAgd2l0aCB0d28gcHJvdG90eXBlczoKPgo+ID0gR2VuZXJpYyBod21vbiB0cmFjZSBl\n" - "dmVudCA9Cj4KPiBUaGlzIG9uZSBhbGxvd3MgYW55IGRyaXZlciB0byBnZW5lcmF0ZSBhIHRyYWNl\n" - "IGV2ZW50IHdoZW5ldmVyIGFueQo+ICJod21vbiBhdHRyaWJ1dGUiIChtZWFzdXJlZCB2YWx1ZSkg\n" - "Z2V0cyB1cGRhdGVkLiBUaGUgcmF0ZSBhdCB3aGljaCB0aGUKPiB1cGRhdGVzIGhhcHBlbiBjYW4g\n" - "YmUgY29udHJvbGxlZCBieSBhbHJlYWR5IGV4aXN0aW5nICJ1cGRhdGVfaW50ZXJ2YWwiCj4gYXR0\n" - "cmlidXRlLgo+Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "Cj4gVFJBQ0VfRVZFTlQoaHdtb25fYXR0cl91cGRhdGUsCj4gCVRQX1BST1RPKHN0cnVjdCBkZXZp\n" - "Y2UgKmRldiwgc3RydWN0IGF0dHJpYnV0ZSAqYXR0ciwgbG9uZyBsb25nIGlucHV0KSwKPiAJVFBf\n" - "QVJHUyhkZXYsIGF0dHIsIGlucHV0KSwKPgo+IAlUUF9TVFJVQ1RfX2VudHJ5KAo+IAkJX19zdHJp\n" - "bmcoICAgICAgIGRldiwJCWRldl9uYW1lKGRldikpCj4gCQlfX3N0cmluZygJYXR0ciwJCWF0dHIt\n" - "Pm5hbWUpCj4gCQlfX2ZpZWxkKAlsb25nIGxvbmcsCWlucHV0KQo+IAkpLAo+Cj4gCVRQX2Zhc3Rf\n" - "YXNzaWduKAo+IAkJX19hc3NpZ25fc3RyKGRldiwgZGV2X25hbWUoZGV2KSk7Cj4gCQlfX2Fzc2ln\n" - "bl9zdHIoYXR0ciwgYXR0ci0+bmFtZSk7Cj4gCQlfX2VudHJ5LT5pbnB1dCA9IGlucHV0Owo+IAkp\n" - "LAo+Cj4gCVRQX3ByaW50aygiJXMgJXMgJWxsZCIsIF9fZ2V0X3N0cihkZXYpLCBfX2dldF9zdHIo\n" - "YXR0ciksIF9fZW50cnktPmlucHV0KQo+ICk7Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "LS0tLS0tLS0tLS0tLS0tLS0tCj4KPiBJdCBnZW5lcmF0ZXMgc3VjaCBmdHJhY2UgbWVzc2FnZToK\n" - "Pgo+IDwuLi4+MjEyLjY3MzEyNjogaHdtb25fYXR0cl91cGRhdGU6IGh3bW9uNCB0ZW1wMV9pbnB1\n" - "dCAzNDM2MQo+Cj4gT25lIGlzc3VlIHdpdGggdGhpcyBpcyB0aGF0IHNvbWUgZXh0ZXJuYWwga25v\n" - "d2xlZGdlIGlzIHJlcXVpcmVkIHRvCj4gcmVsYXRlIGEgbnVtYmVyIHRvIGEgcHJvY2Vzc29yIGNv\n" - "cmUuIE9yIG1heWJlIGl0J3Mgbm90IGFuIGlzc3VlIGF0IGFsbAo+IGJlY2F1c2UgaXQgc2hvdWxk\n" - "IGJlIGxlZnQgZm9yIHRoZSB1c2VyKHNwYWNlKT8KPgo+ID0gQ1BVIHBvd2VyL2VuZXJneS90ZW1w\n" - "ZXJhdHVyZSB0cmFjZSBldmVudCA9Cj4KPiBUaGlzIG9uZSBpcyBkZXNpZ25lZCB0byBlbXBoYXNp\n" - "emUgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIG1lYXN1cmVkCj4gdmFsdWUgKHdoZXRoZXIgaXQg\n" - "aXMgZW5lcmd5LCB0ZW1wZXJhdHVyZSBvciBhbnkgb3RoZXIgcGh5c2ljYWwKPiBwaGVub21lbmEs\n" - "IHJlYWxseSkgYW5kIENQVXMsIHNvIGl0IGlzIHF1aXRlIHNwZWNpZmljICh0b28gc3BlY2lmaWM/\n" - "KQo+Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVFJB\n" - "Q0VfRVZFTlQoY3B1c19lbnZpcm9ubWVudCwKPiAJVFBfUFJPVE8oY29uc3Qgc3RydWN0IGNwdW1h\n" - "c2sgKmNwdXMsIGxvbmcgbG9uZyB2YWx1ZSwgY2hhciB1bml0KSwKPiAJVFBfQVJHUyhjcHVzLCB2\n" - "YWx1ZSwgdW5pdCksCj4KPiAJVFBfU1RSVUNUX19lbnRyeSgKPiAJCV9fYXJyYXkoCXVuc2lnbmVk\n" - "IGNoYXIsCWNwdXMsCXNpemVvZihzdHJ1Y3QgY3B1bWFzaykpCj4gCQlfX2ZpZWxkKAlsb25nIGxv\n" - "bmcsCXZhbHVlKQo+IAkJX19maWVsZCgJY2hhciwJCXVuaXQpCj4gCSksCj4KPiAJVFBfZmFzdF9h\n" - "c3NpZ24oCj4gCQltZW1jcHkoX19lbnRyeS0+Y3B1cywgY3B1cywgc2l6ZW9mKHN0cnVjdCBjcHVt\n" - "YXNrKSk7Cj4gCQlfX2VudHJ5LT52YWx1ZSA9IHZhbHVlOwo+IAkJX19lbnRyeS0+dW5pdCA9IHVu\n" - "aXQ7Cj4gCSksCj4KPiAJVFBfcHJpbnRrKCJjcHVzICVzICVsbGRbJWNdIiwKPiAJCV9fcHJpbnRf\n" - "Y3B1bWFzaygoc3RydWN0IGNwdW1hc2sgKilfX2VudHJ5LT5jcHVzKSwKPiAJCV9fZW50cnktPnZh\n" - "bHVlLCBfX2VudHJ5LT51bml0KQo+ICk7Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "LS0tLS0tLS0tLS0tLS0tCj4KPiBBbmQgdGhlIGVxdWl2YWxlbnQgZnRyYWNlIG1lc3NhZ2UgaXM6\n" - "Cj4KPiA8Li4uPjEyNy4wNjMxMDc6IGNwdXNfZW52aXJvbm1lbnQ6IGNwdXMgMCwxLDIsMyAzNDM2\n" - "MVtDXQo+Cj4gSXQncyBhIGNwdW1hc2ssIG5vdCBqdXN0IHNpbmdsZSBjcHUgaWQsIGJlY2F1c2Ug\n" - "dGhlIHNlbnNvciBtYXkgbWVhc3VyZQo+IHRoZSB2YWx1ZSBwZXIgc2V0IG9mIENQVXMsIGVnLiBh\n" - "IHRlbXBlcmF0dXJlIG9mIHRoZSB3aG9sZSBzaWxpY29uIGRpZQo+IChzbyBhbGwgdGhlIGNvcmVz\n" - "KSBvciBhbiBlbmVyZ3kgY29uc3VtZWQgYnkgYSBzdWJzZXQgb2YgY29yZXMgKHRoaXMKPiBpcyBt\n" - "eSBwYXJ0aWN1bGFyIHVzZSBjYXNlIC0gdHdvIG1ldGVycyBtb25pdG9yIGEgY2x1c3RlciBvZiB0\n" - "d28KPiBwcm9jZXNzb3JzIGFuZCBhIGNsdXN0ZXIgb2YgdGhyZWUgcHJvY2Vzc29ycywgYWxsIHdv\n" - "cmtpbmcgYXMgYSBTTVAKPiBzeXN0ZW0pLgo+Cj4gT2YgY291cnNlIHRoZSBjcHVzIF9fYXJyYXkg\n" - "Y291bGQgYmUgYWN0dWFsbHkgYSBzcGVjaWFsIF9fY3B1bWFzayBmaWVsZAo+IHR5cGUgKEkndmUg\n" - "anVzdCBoYWNrZWQgdGhlIF9fcHJpbnRfY3B1bWFzayBzbyBmYXIpLiBBbmQgSSd2ZSBqdXN0Cj4g\n" - "cmVhbGlzZWQgdGhhdCB0aGUgdW5pdCBmaWVsZCBzaG91bGQgYWN0dWFsbHkgYmUgYSBzdHJpbmcg\n" - "dG8gYWxsb3cgdW5pdAo+IHByZWZpeGVzIHRvIGJlIHNwZWNpZmllZCAodGhlIGFib3ZlIHNob3Vs\n" - "ZCBvYnZpb3VzbHkgYmUgIjM0MzYxW21DXSIKPiBub3QgIltDXSIpLiBBbHNvIC0gZXhjdXNlIHRo\n" - "ZSAiY3B1c19lbnZpcm9ubWVudCIgbmFtZSAtIHRoaXMgd2FzIHRoZQo+IGJlc3QgSSB3YXMgYWJs\n" - "ZSB0byBjb21lIHVwIHdpdGggYXQgdGhlIHRpbWUgYW5kIEknbSBlYWdlciB0byBhY2NlcHQKPiBh\n" - "bnkgYWx0ZXJuYXRpdmUgc3VnZ2VzdGlvbnMgOi0pCgpBIHRob3VnaHQgb24gdGhhdC4uLiBmcm9t\n" - "IGFuIFNvQyBwZXJzcGVjdGl2ZSB0aGVyZSBhcmUgb3RoZXIgaW50ZXJlc3RpbmcgCnBvd2VyIHJh\n" - "aWxzIHRoYW4gZ28gdG8ganVzdCB0aGUgQ1BVIGNvcmUuICBGb3IgZXhhbXBsZSBERFIgcG93ZXIg\n" - "YW5kIApyYWlscyBpbnZvbHZlZCB3aXRoIG90aGVyIElQIHVuaXRzIG9uIHRoZSBTb0Mgc3VjaCBh\n" - "cyAzRCBncmFwaGljcyB1bml0LiAKICBTbyB0eWluZyBvbmUgbnVtYmVyIHRvIHNwZWNpZmljYWxs\n" - "eSBhIENQVSBjb3JlIGRvZXMgbm90IHNvdW5kIGxpa2UgCml0J3MgZW5vdWdoLgoKPiA9PT0gT3B0\n" - "aW9uIDI6IGh3bW9uIHBlcmYgUE1VID09PQo+Cj4gQWx0aG91Z2ggdGhlIHRyYWNlIGV2ZW50IG1h\n" - "a2VzIGl0IHBvc3NpYmxlIHRvIG9idGFpbiBpbnRlcmVzdGluZwo+IGluZm9ybWF0aW9uIHVzaW5n\n" - "IHBlcmYsIHRoZSB1c2VyIHdvdWxkbid0IGJlIGFibGUgdG8gdHJlYXQgdGhlCj4gZW5lcmd5IG1l\n" - "dGVyIGFzIGEgbm9ybWFsIGRhdGEgc291cmNlLiBJbiBwYXJ0aWN1bGFyIHRoZXJlIHdvdWxkCj4g\n" - "YmUgbm8gd2F5IG9mIGNyZWF0aW5nIGEgZ3JvdXAgb2YgZXZlbnRzIGNvbnNpc3RpbmcgZWcuIG9m\n" - "IGEKPiAibm9ybWFsIiBsZWFkZXIgKGVnLiBjYWNoZSBtaXNzIGV2ZW50KSB0cmlnZ2VyaW5nIGVu\n" - "ZXJneSBtZXRlcgo+IHJlYWQuIFRoZSBvbmx5IHdheSB0byBnZXQgdGhpcyBkb25lIGlzIHRvIGlt\n" - "cGxlbWVudCBhIHBlcmYgUE1VCj4gYmFja2VuZCBwcm92aWRpbmcgImVudmlyb25tZW50YWwgZGF0\n" - "YSIgdG8gdGhlIHVzZXIuCgpJbiB0ZXJtcyBvZiBsaWtlIHBlcmYgdG9wIGRvbid0IHRoaW5rIGl0\n" - "J2xsIGJlIHBvc3NpYmxlIHRvIGtub3cgd2hlbiB0byAKc2FtcGxlIHRoZSBhY3F1aXNpdGlvbiBo\n" - "YXJkd2FyZSB0byB0aWUgdGhlIHJlc3VsdCB0byBhIHBhcnRpY3VsYXIgbGluZSAKb2YgY29kZSwg\n" - "ZXZlbiBpZiBpdCBoYWQgdGhlIGJhbmR3aWR0aCB0byBkbyB0aGF0LiAgUG93ZXIgcmVhZGluZ3Mg\n" - "YXJlIApsaWtlbHkgdG8gbGFnIGFjdGl2aXRpZXMgb24gdGhlIGNwdSBzb21ld2hhdCwgY29uc2lk\n" - "ZXJpbmcgc3ViLW5zIGNvcmUgCmNsb2NrcywgZXNwZWNpYWxseSBpZiBpdCdzIGFjdHVhbGx5IG1l\n" - "YXN1cmluZyB0aGUgaW5wdXQgc2lkZSBvZiBhIHJlZ3VsYXRvci4KCj4gPSBIaWdoLWxldmVsIGh3\n" - "bW9uIEFQSSBhbmQgUE1VID0KPgo+IEN1cnJlbnQgaHdtb24gc3Vic3lzdGVtIGRvZXMgbm90IHBy\n" - "b3ZpZGUgYW55IGFic3RyYWN0aW9uIGZvciB0aGUKPiBtZWFzdXJlZCB2YWx1ZXMgYW5kIHJlcXVp\n" - "cmVzIHBhcnRpY3VsYXIgZHJpdmVycyB0byBjcmVhdGUgc3BlY2lmaWVkCj4gc3lzZnMgYXR0cmli\n" - "dXRlcyB0aGFuIHVzZWQgYnkgdXNlcnNwYWNlIGxpYnNlbnNvcnMuIFRoaXMgbWFrZXMKPiB0aGUg\n" - "ZnJhbWV3b3JrIHVsdGltYXRlbHkgZmxleGlibGUgYW5kIHVsdGltYXRlbHkgaGFyZCB0byBhY2Nl\n" - "c3MKPiBmcm9tIHdpdGhpbiB0aGUga2VybmVsLi4uCj4KPiBXaGF0IGNvdWxkIGJlIGRvbmUgaGVy\n" - "ZSBpcyBzb21lIChzaW1wbGUpIEFQSSB0byByZWdpc3RlciB0aGUKPiBtZWFzdXJlZCB2YWx1ZXMg\n" - "d2l0aCB0aGUgaHdtb24gY29yZSB3aGljaCB3b3VsZCByZXN1bHQgaW4gY3JlYXRpbmcKPiBlcXVp\n" - "dmFsZW50IHN5c2ZzIGF0dHJpYnV0ZXMgYXV0b21hZ2ljYWxseSwgYnV0IGFsc28gYWxsb3cgYQo+\n" - "IGluLWtlcm5lbCBBUEkgZm9yIHZhbHVlcyBlbnVtZXJhdGlvbiBhbmQgYWNjZXNzLiBUaGF0IHdh\n" - "eSB0aGUgY29yZQo+IGNvdWxkIGFsc28gcmVnaXN0ZXIgYSAiaHdtb24gUE1VIiB3aXRoIHRoZSBw\n" - "ZXJmIGZyYW1ld29yayBwcm92aWRpbmcKPiBkYXRhIGZyb20gYWxsICJjb21wbGlhbnQiIGRyaXZl\n" - "cnMuCj4KPiA9IEEgZHJpdmVyLXNwZWNpZmljIFBNVSA9Cj4KPiBPZiBjb3Vyc2UgYSBwYXJ0aWN1\n" - "bGFyIGRyaXZlciBjb3VsZCByZWdpc3RlciBpdHMgb3duIHBlcmYgUE1VIG9uIGl0cwo+IG93bi4g\n" - "SXQncyBjZXJ0YWlubHkgYW4gb3B0aW9uLCBqdXN0IHZlcnkgc3Vib3B0aW1hbCBpbiBteSBvcGlu\n" - "aW9uLgo+IE9yIG1heWJlIG5vdD8gTWF5YmUgdGhlIHRhc2sgaXMgc28gc3BlY2lhbGl6ZWQgdGhh\n" - "dCBpdCBtYWtlcyBzZW5zZT8KPgo+Cj4KPiA9PT0gT3B0aW9uIDM6IENQVSBwb3dlcihlbmVyZ3kp\n" - "IG1vbml0b3JpbmcgZnJhbWV3b3JrID09PQo+Cj4gQW5kIGxhc3QgYnV0IG5vdCBsZWFzdCwgbWF5\n" - "YmUgdGhlIHByb2JsZW0gZGVzZXJ2ZXMgc29tZSBkZWRpY2F0ZWQKPiBBUEk/IFNvbWV0aGluZyB0\n" - "aGF0IHdvdWxkIHRha2UgcHJvdmlkZXJzIGFuZCBmZWVkIHRoZWlyIGRhdGEgaW50bwo+IGludGVy\n" - "ZXN0ZWQgcGFydGllcywgaW4gcGFydGljdWxhciBhIHBlcmYgUE1VIGltcGxlbWVudGF0aW9uIGFu\n" - "ZAo+IGNwdWZyZXEgZ292ZXJub3JzPwo+Cj4gTWF5YmUgaXQgY291bGQgYmUgYW4gZXh0ZW5zaW9u\n" - "IHRvIHRoZSB0aGVybWFsIGZyYW1ld29yaz8gSXQgYWxyZWFkeQo+IGdpdmVzIHNvbWUgbWVhbmlu\n" - "ZyB0byBhIHBoeXNpY2FsIHBoZW5vbWVuYS4gQWRkaW5nIG90aGVyLCByZWxhdGVkIG9uZXMKPiBs\n" - "aWtlIGVuZXJneSwgYW5kIHJlbGF0aW5nIGl0IHRvIGNwdSBjb3JlcyBjb3VsZCBtYWtlIHNvbWUg\n" - "c2Vuc2UuCgpJZiB5b3UgdHVybiB0aGUgcHJvYmxlbSB1cHNpZGUgZG93biB0byBzb2x2ZSB0aGUg\n" - "cmVwcmVzZW50YXRpb24gcXVlc3Rpb24gCmZpcnN0LCBtYXliZSB0aGVyZSdzIGEgd2F5IGZvcndh\n" - "cmQgZGVmaW5pbmcgdGhlICJwb3dlciB0cmVlIiBpbiB0ZXJtcyBvZiAKcmVndWxhdG9ycywgYW5k\n" - "IHRoZW4gYWRkaW5nIHNvbWV0aGluZyBpbiBzdHJ1Y3QgcmVndWxhdG9yIHRoYXQgc3BhbXMgCnJl\n" - "YWRlcnMgd2l0aCB0aW1lc3RhbXBlZCByZXN1bHRzIGlmIHRoZSByZWd1bGF0b3IgaGFzIGEgcG93\n" - "ZXIgbW9uaXRvcmluZyAKY2FwYWJpbGl0eS4KClRoZW4geW91IGNhbiBtYXAgdGhlIHJlZ3VsYXRv\n" - "cnMgaW4gdGhlIHBvd2VyIHRyZWUgdG8gcmVhbCBkZXZpY2VzIGJ5IHRoZSAKbmFtZXMgb3IgdGhl\n" - "IHN1cHBseSBzdHVmZi4gIEp1c3QgYSB0aG91Z2h0LgoKLUFuZHkKCi0tIApBbmR5IEdyZWVuIHwg\n" - "VEkgTGFuZGluZyBUZWFtIExlYWRlcgpMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2Fy\n" - "ZSBmb3IgQVJNIFNvQ3MgfCBGb2xsb3cgTGluYXJvCmh0dHA6Ly9mYWNlYm9vay5jb20vcGFnZXMv\n" - "TGluYXJvLzE1NTk3NDU4MTA5MTEwNiAgLSAKaHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFyb29y\n" - "ZyAtIGh0dHA6Ly9saW5hcm8ub3JnL2xpbmFyby1ibG9nCgpfX19fX19fX19fX19fX19fX19fX19f\n" - "X19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5z\n" - "b3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xp\n" - c3RpbmZvL2xtLXNlbnNvcnM + "On 10/23/12 19:30, the mail apparently from Pawel Moll included:\n" + "> Greetings All,\n" + ">\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. The second\n" + "> most frequent request is about providing it to a \"energy aware\"\n" + "> cpufreq governor.\n" + ">\n" + "> I've came up with three (non-mutually exclusive) options. I will\n" + "> appreciate any other ideas and comments (including \"it makes not sense\n" + "> whatsoever\" ones, with justification). Of course I am more than willing\n" + "> to spend time on prototyping anything that seems reasonable and propose\n" + "> patches.\n" + ">\n" + ">\n" + ">\n" + "> === Option 1: Trace event ===\n" + ">\n" + "> This seems to be the \"cheapest\" option. Simply defining a trace event\n" + "> that can be generated by a hwmon (or any other) driver makes the\n" + "> interesting data immediately available to any ftrace/perf user. Of\n" + "> course it doesn't really help with the cpufreq case, but seems to be\n" + "> a good place to start with.\n" + ">\n" + "> The question is how to define it... I've came up with two prototypes:\n" + ">\n" + "> = Generic hwmon trace event =\n" + ">\n" + "> This one allows any driver to generate a trace event whenever any\n" + "> \"hwmon attribute\" (measured value) gets updated. The rate at which the\n" + "> updates happen can be controlled by already existing \"update_interval\"\n" + "> attribute.\n" + ">\n" + "> 8<-------------------------------------------\n" + "> TRACE_EVENT(hwmon_attr_update,\n" + "> \tTP_PROTO(struct device *dev, struct attribute *attr, long long input),\n" + "> \tTP_ARGS(dev, attr, input),\n" + ">\n" + "> \tTP_STRUCT__entry(\n" + "> \t\t__string( dev,\t\tdev_name(dev))\n" + "> \t\t__string(\tattr,\t\tattr->name)\n" + "> \t\t__field(\tlong long,\tinput)\n" + "> \t),\n" + ">\n" + "> \tTP_fast_assign(\n" + "> \t\t__assign_str(dev, dev_name(dev));\n" + "> \t\t__assign_str(attr, attr->name);\n" + "> \t\t__entry->input = input;\n" + "> \t),\n" + ">\n" + "> \tTP_printk(\"%s %s %lld\", __get_str(dev), __get_str(attr), __entry->input)\n" + "> );\n" + "> 8<-------------------------------------------\n" + ">\n" + "> It generates such ftrace message:\n" + ">\n" + "> <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361\n" + ">\n" + "> One issue with this is that some external knowledge is required to\n" + "> relate a number to a processor core. Or maybe it's not an issue at all\n" + "> because it should be left for the user(space)?\n" + ">\n" + "> = CPU power/energy/temperature trace event =\n" + ">\n" + "> This one is designed to emphasize the relation between the measured\n" + "> value (whether it is energy, temperature or any other physical\n" + "> phenomena, really) and CPUs, so it is quite specific (too specific?)\n" + ">\n" + "> 8<-------------------------------------------\n" + "> TRACE_EVENT(cpus_environment,\n" + "> \tTP_PROTO(const struct cpumask *cpus, long long value, char unit),\n" + "> \tTP_ARGS(cpus, value, unit),\n" + ">\n" + "> \tTP_STRUCT__entry(\n" + "> \t\t__array(\tunsigned char,\tcpus,\tsizeof(struct cpumask))\n" + "> \t\t__field(\tlong long,\tvalue)\n" + "> \t\t__field(\tchar,\t\tunit)\n" + "> \t),\n" + ">\n" + "> \tTP_fast_assign(\n" + "> \t\tmemcpy(__entry->cpus, cpus, sizeof(struct cpumask));\n" + "> \t\t__entry->value = value;\n" + "> \t\t__entry->unit = unit;\n" + "> \t),\n" + ">\n" + "> \tTP_printk(\"cpus %s %lld[%c]\",\n" + "> \t\t__print_cpumask((struct cpumask *)__entry->cpus),\n" + "> \t\t__entry->value, __entry->unit)\n" + "> );\n" + "> 8<-------------------------------------------\n" + ">\n" + "> And the equivalent ftrace message is:\n" + ">\n" + "> <...>127.063107: cpus_environment: cpus 0,1,2,3 34361[C]\n" + ">\n" + "> It's a cpumask, not just single cpu id, because the sensor may measure\n" + "> the value per set of CPUs, eg. a temperature of the whole silicon die\n" + "> (so all the cores) or an energy consumed by a subset of cores (this\n" + "> is my particular use case - two meters monitor a cluster of two\n" + "> processors and a cluster of three processors, all working as a SMP\n" + "> system).\n" + ">\n" + "> Of course the cpus __array could be actually a special __cpumask field\n" + "> type (I've just hacked the __print_cpumask so far). And I've just\n" + "> realised that the unit field should actually be a string to allow unit\n" + "> prefixes to be specified (the above should obviously be \"34361[mC]\"\n" + "> not \"[C]\"). Also - excuse the \"cpus_environment\" name - this was the\n" + "> best I was able to come up with at the time and I'm eager to accept\n" + "> any alternative suggestions :-)\n" + "\n" + "A thought on that... from an SoC perspective there are other interesting \n" + "power rails than go to just the CPU core. For example DDR power and \n" + "rails involved with other IP units on the SoC such as 3D graphics unit. \n" + " So tying one number to specifically a CPU core does not sound like \n" + "it's enough.\n" + "\n" + "> === Option 2: hwmon perf PMU ===\n" + ">\n" + "> Although the trace event makes it possible to obtain interesting\n" + "> information using perf, the user wouldn't be able to treat the\n" + "> energy meter as a normal data source. In particular there would\n" + "> be no way of creating a group of events consisting eg. of a\n" + "> \"normal\" leader (eg. cache miss event) triggering energy meter\n" + "> read. The only way to get this done is to implement a perf PMU\n" + "> backend providing \"environmental data\" to the user.\n" + "\n" + "In terms of like perf top don't think it'll be possible to know when to \n" + "sample the acquisition hardware to tie the result to a particular line \n" + "of code, even if it had the bandwidth to do that. Power readings are \n" + "likely to lag activities on the cpu somewhat, considering sub-ns core \n" + "clocks, especially if it's actually measuring the input side of a regulator.\n" + "\n" + "> = High-level hwmon API and PMU =\n" + ">\n" + "> Current hwmon subsystem does not provide any abstraction for the\n" + "> measured values and requires particular drivers to create specified\n" + "> sysfs attributes than used by userspace libsensors. This makes\n" + "> the framework ultimately flexible and ultimately hard to access\n" + "> from within the kernel...\n" + ">\n" + "> What could be done here is some (simple) API to register the\n" + "> measured values with the hwmon core which would result in creating\n" + "> equivalent sysfs attributes automagically, but also allow a\n" + "> in-kernel API for values enumeration and access. That way the core\n" + "> could also register a \"hwmon PMU\" with the perf framework providing\n" + "> data from all \"compliant\" drivers.\n" + ">\n" + "> = A driver-specific PMU =\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" + ">\n" + ">\n" + "> === Option 3: CPU power(energy) monitoring framework ===\n" + ">\n" + "> And last but not least, maybe the problem deserves some dedicated\n" + "> API? Something that would take providers and feed their data into\n" + "> interested parties, in particular a perf PMU implementation and\n" + "> cpufreq governors?\n" + ">\n" + "> Maybe it could be an extension to the thermal framework? It already\n" + "> gives some meaning to a physical phenomena. Adding other, related ones\n" + "> like energy, and relating it to cpu cores could make some sense.\n" + "\n" + "If you turn the problem upside down to solve the representation question \n" + "first, maybe there's a way forward defining the \"power tree\" in terms of \n" + "regulators, and then adding something in struct regulator that spams \n" + "readers with timestamped results if the regulator has a power monitoring \n" + "capability.\n" + "\n" + "Then you can map the regulators in the power tree to real devices by the \n" + "names or the supply stuff. Just a thought.\n" + "\n" + "-Andy\n" + "\n" + "-- \n" + "Andy Green | TI Landing Team Leader\n" + "Linaro.org ? Open source software for ARM SoCs | Follow Linaro\n" + "http://facebook.com/pages/Linaro/155974581091106 - \n" + http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog -22232a0f12680e64197ada3f65b77e0155a7c984437b3814dc404f223114fb98 +97b68373726525f312db381d50fafcf99c24d20ee4136d4eba5e4b84a66f7edc
diff --git a/a/1.txt b/N2/1.txt index eb01584..aeb5726 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,140 +1,192 @@ -T24gMTAvMjMvMTIgMTk6MzAsIHRoZSBtYWlsIGFwcGFyZW50bHkgZnJvbSBQYXdlbCBNb2xsIGlu -Y2x1ZGVkOgo+IEdyZWV0aW5ncyBBbGwsCj4KPiBNb3JlIGFuZCBtb3JlIG9mIHBlb3BsZSBhcmUg -Z2V0dGluZyBpbnRlcmVzdGVkIGluIHRoZSBzdWJqZWN0IG9mIHBvd2VyCj4gKGVuZXJneSkgY29u -c3VtcHRpb24gbW9uaXRvcmluZy4gV2UgaGF2ZSBzb21lIGV4dGVybmFsIHRvb2xzIGxpa2UKPiAi -YmF0dGVyeSBzaW11bGF0b3JzIiwgZW5lcmd5IHByb2JlcyBldGMuLCBidXQgc29tZSB0YXJnZXRz -IGNhbiBtZWFzdXJlCj4gdGhlaXIgcG93ZXIgdXNhZ2Ugb24gdGhlaXIgb3duLgo+Cj4gVHJhZGl0 -aW9uYWxseSBzdWNoIGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIgdmlhIGh3bW9u -IHN5c2ZzCj4gaW50ZXJmYWNlLCBhbmQgdGhhdCdzIGV4YWN0bHkgd2hhdCBJIGRpZCBmb3IgIm15 -IiBwbGF0Zm9ybSAtIEkgaGF2ZQo+IGEgL3N5cy9jbGFzcy9od21vbi9od21vbiovZGV2aWNlL2Vu -ZXJneSpfaW5wdXQgYW5kIHRoaXMgd2FzIGdvb2QKPiBlbm91Z2ggdG8gZHJhdyBwcmV0dHkgZ3Jh -cGhzIGluIHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4KPiBOb3cgSSBhbSBnZXR0 -aW5nIG5ldyByZXF1ZXN0cyB0byBkbyBtb3JlIHdpdGggdGhpcyBkYXRhLiBJbiBwYXJ0aWN1bGFy -Cj4gSSdtIGFza2VkIGhvdyB0byBhZGQgc3VjaCBpbmZvcm1hdGlvbiB0byBmdHJhY2UvcGVyZiBv -dXRwdXQuIFRoZSBzZWNvbmQKPiBtb3N0IGZyZXF1ZW50IHJlcXVlc3QgaXMgYWJvdXQgcHJvdmlk -aW5nIGl0IHRvIGEgImVuZXJneSBhd2FyZSIKPiBjcHVmcmVxIGdvdmVybm9yLgo+Cj4gSSd2ZSBj -YW1lIHVwIHdpdGggdGhyZWUgKG5vbi1tdXR1YWxseSBleGNsdXNpdmUpIG9wdGlvbnMuIEkgd2ls -bAo+IGFwcHJlY2lhdGUgYW55IG90aGVyIGlkZWFzIGFuZCBjb21tZW50cyAoaW5jbHVkaW5nICJp -dCBtYWtlcyBub3Qgc2Vuc2UKPiB3aGF0c29ldmVyIiBvbmVzLCB3aXRoIGp1c3RpZmljYXRpb24p -LiBPZiBjb3Vyc2UgSSBhbSBtb3JlIHRoYW4gd2lsbGluZwo+IHRvIHNwZW5kIHRpbWUgb24gcHJv -dG90eXBpbmcgYW55dGhpbmcgdGhhdCBzZWVtcyByZWFzb25hYmxlIGFuZCBwcm9wb3NlCj4gcGF0 -Y2hlcy4KPgo+Cj4KPiA9PT0gT3B0aW9uIDE6IFRyYWNlIGV2ZW50ID09PQo+Cj4gVGhpcyBzZWVt -cyB0byBiZSB0aGUgImNoZWFwZXN0IiBvcHRpb24uIFNpbXBseSBkZWZpbmluZyBhIHRyYWNlIGV2 -ZW50Cj4gdGhhdCBjYW4gYmUgZ2VuZXJhdGVkIGJ5IGEgaHdtb24gKG9yIGFueSBvdGhlcikgZHJp -dmVyIG1ha2VzIHRoZQo+IGludGVyZXN0aW5nIGRhdGEgaW1tZWRpYXRlbHkgYXZhaWxhYmxlIHRv -IGFueSBmdHJhY2UvcGVyZiB1c2VyLiBPZgo+IGNvdXJzZSBpdCBkb2Vzbid0IHJlYWxseSBoZWxw -IHdpdGggdGhlIGNwdWZyZXEgY2FzZSwgYnV0IHNlZW1zIHRvIGJlCj4gYSBnb29kIHBsYWNlIHRv -IHN0YXJ0IHdpdGguCj4KPiBUaGUgcXVlc3Rpb24gaXMgaG93IHRvIGRlZmluZSBpdC4uLiBJJ3Zl -IGNhbWUgdXAgd2l0aCB0d28gcHJvdG90eXBlczoKPgo+ID0gR2VuZXJpYyBod21vbiB0cmFjZSBl -dmVudCA9Cj4KPiBUaGlzIG9uZSBhbGxvd3MgYW55IGRyaXZlciB0byBnZW5lcmF0ZSBhIHRyYWNl -IGV2ZW50IHdoZW5ldmVyIGFueQo+ICJod21vbiBhdHRyaWJ1dGUiIChtZWFzdXJlZCB2YWx1ZSkg -Z2V0cyB1cGRhdGVkLiBUaGUgcmF0ZSBhdCB3aGljaCB0aGUKPiB1cGRhdGVzIGhhcHBlbiBjYW4g -YmUgY29udHJvbGxlZCBieSBhbHJlYWR5IGV4aXN0aW5nICJ1cGRhdGVfaW50ZXJ2YWwiCj4gYXR0 -cmlidXRlLgo+Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t -Cj4gVFJBQ0VfRVZFTlQoaHdtb25fYXR0cl91cGRhdGUsCj4gCVRQX1BST1RPKHN0cnVjdCBkZXZp -Y2UgKmRldiwgc3RydWN0IGF0dHJpYnV0ZSAqYXR0ciwgbG9uZyBsb25nIGlucHV0KSwKPiAJVFBf -QVJHUyhkZXYsIGF0dHIsIGlucHV0KSwKPgo+IAlUUF9TVFJVQ1RfX2VudHJ5KAo+IAkJX19zdHJp -bmcoICAgICAgIGRldiwJCWRldl9uYW1lKGRldikpCj4gCQlfX3N0cmluZygJYXR0ciwJCWF0dHIt -Pm5hbWUpCj4gCQlfX2ZpZWxkKAlsb25nIGxvbmcsCWlucHV0KQo+IAkpLAo+Cj4gCVRQX2Zhc3Rf -YXNzaWduKAo+IAkJX19hc3NpZ25fc3RyKGRldiwgZGV2X25hbWUoZGV2KSk7Cj4gCQlfX2Fzc2ln -bl9zdHIoYXR0ciwgYXR0ci0+bmFtZSk7Cj4gCQlfX2VudHJ5LT5pbnB1dCA9IGlucHV0Owo+IAkp -LAo+Cj4gCVRQX3ByaW50aygiJXMgJXMgJWxsZCIsIF9fZ2V0X3N0cihkZXYpLCBfX2dldF9zdHIo -YXR0ciksIF9fZW50cnktPmlucHV0KQo+ICk7Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t -LS0tLS0tLS0tLS0tLS0tLS0tCj4KPiBJdCBnZW5lcmF0ZXMgc3VjaCBmdHJhY2UgbWVzc2FnZToK -Pgo+IDwuLi4+MjEyLjY3MzEyNjogaHdtb25fYXR0cl91cGRhdGU6IGh3bW9uNCB0ZW1wMV9pbnB1 -dCAzNDM2MQo+Cj4gT25lIGlzc3VlIHdpdGggdGhpcyBpcyB0aGF0IHNvbWUgZXh0ZXJuYWwga25v -d2xlZGdlIGlzIHJlcXVpcmVkIHRvCj4gcmVsYXRlIGEgbnVtYmVyIHRvIGEgcHJvY2Vzc29yIGNv -cmUuIE9yIG1heWJlIGl0J3Mgbm90IGFuIGlzc3VlIGF0IGFsbAo+IGJlY2F1c2UgaXQgc2hvdWxk -IGJlIGxlZnQgZm9yIHRoZSB1c2VyKHNwYWNlKT8KPgo+ID0gQ1BVIHBvd2VyL2VuZXJneS90ZW1w -ZXJhdHVyZSB0cmFjZSBldmVudCA9Cj4KPiBUaGlzIG9uZSBpcyBkZXNpZ25lZCB0byBlbXBoYXNp -emUgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIG1lYXN1cmVkCj4gdmFsdWUgKHdoZXRoZXIgaXQg -aXMgZW5lcmd5LCB0ZW1wZXJhdHVyZSBvciBhbnkgb3RoZXIgcGh5c2ljYWwKPiBwaGVub21lbmEs -IHJlYWxseSkgYW5kIENQVXMsIHNvIGl0IGlzIHF1aXRlIHNwZWNpZmljICh0b28gc3BlY2lmaWM/ -KQo+Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVFJB -Q0VfRVZFTlQoY3B1c19lbnZpcm9ubWVudCwKPiAJVFBfUFJPVE8oY29uc3Qgc3RydWN0IGNwdW1h -c2sgKmNwdXMsIGxvbmcgbG9uZyB2YWx1ZSwgY2hhciB1bml0KSwKPiAJVFBfQVJHUyhjcHVzLCB2 -YWx1ZSwgdW5pdCksCj4KPiAJVFBfU1RSVUNUX19lbnRyeSgKPiAJCV9fYXJyYXkoCXVuc2lnbmVk -IGNoYXIsCWNwdXMsCXNpemVvZihzdHJ1Y3QgY3B1bWFzaykpCj4gCQlfX2ZpZWxkKAlsb25nIGxv -bmcsCXZhbHVlKQo+IAkJX19maWVsZCgJY2hhciwJCXVuaXQpCj4gCSksCj4KPiAJVFBfZmFzdF9h -c3NpZ24oCj4gCQltZW1jcHkoX19lbnRyeS0+Y3B1cywgY3B1cywgc2l6ZW9mKHN0cnVjdCBjcHVt -YXNrKSk7Cj4gCQlfX2VudHJ5LT52YWx1ZSA9IHZhbHVlOwo+IAkJX19lbnRyeS0+dW5pdCA9IHVu -aXQ7Cj4gCSksCj4KPiAJVFBfcHJpbnRrKCJjcHVzICVzICVsbGRbJWNdIiwKPiAJCV9fcHJpbnRf -Y3B1bWFzaygoc3RydWN0IGNwdW1hc2sgKilfX2VudHJ5LT5jcHVzKSwKPiAJCV9fZW50cnktPnZh -bHVlLCBfX2VudHJ5LT51bml0KQo+ICk7Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t -LS0tLS0tLS0tLS0tLS0tCj4KPiBBbmQgdGhlIGVxdWl2YWxlbnQgZnRyYWNlIG1lc3NhZ2UgaXM6 -Cj4KPiA8Li4uPjEyNy4wNjMxMDc6IGNwdXNfZW52aXJvbm1lbnQ6IGNwdXMgMCwxLDIsMyAzNDM2 -MVtDXQo+Cj4gSXQncyBhIGNwdW1hc2ssIG5vdCBqdXN0IHNpbmdsZSBjcHUgaWQsIGJlY2F1c2Ug -dGhlIHNlbnNvciBtYXkgbWVhc3VyZQo+IHRoZSB2YWx1ZSBwZXIgc2V0IG9mIENQVXMsIGVnLiBh -IHRlbXBlcmF0dXJlIG9mIHRoZSB3aG9sZSBzaWxpY29uIGRpZQo+IChzbyBhbGwgdGhlIGNvcmVz -KSBvciBhbiBlbmVyZ3kgY29uc3VtZWQgYnkgYSBzdWJzZXQgb2YgY29yZXMgKHRoaXMKPiBpcyBt -eSBwYXJ0aWN1bGFyIHVzZSBjYXNlIC0gdHdvIG1ldGVycyBtb25pdG9yIGEgY2x1c3RlciBvZiB0 -d28KPiBwcm9jZXNzb3JzIGFuZCBhIGNsdXN0ZXIgb2YgdGhyZWUgcHJvY2Vzc29ycywgYWxsIHdv -cmtpbmcgYXMgYSBTTVAKPiBzeXN0ZW0pLgo+Cj4gT2YgY291cnNlIHRoZSBjcHVzIF9fYXJyYXkg -Y291bGQgYmUgYWN0dWFsbHkgYSBzcGVjaWFsIF9fY3B1bWFzayBmaWVsZAo+IHR5cGUgKEkndmUg -anVzdCBoYWNrZWQgdGhlIF9fcHJpbnRfY3B1bWFzayBzbyBmYXIpLiBBbmQgSSd2ZSBqdXN0Cj4g -cmVhbGlzZWQgdGhhdCB0aGUgdW5pdCBmaWVsZCBzaG91bGQgYWN0dWFsbHkgYmUgYSBzdHJpbmcg -dG8gYWxsb3cgdW5pdAo+IHByZWZpeGVzIHRvIGJlIHNwZWNpZmllZCAodGhlIGFib3ZlIHNob3Vs -ZCBvYnZpb3VzbHkgYmUgIjM0MzYxW21DXSIKPiBub3QgIltDXSIpLiBBbHNvIC0gZXhjdXNlIHRo -ZSAiY3B1c19lbnZpcm9ubWVudCIgbmFtZSAtIHRoaXMgd2FzIHRoZQo+IGJlc3QgSSB3YXMgYWJs -ZSB0byBjb21lIHVwIHdpdGggYXQgdGhlIHRpbWUgYW5kIEknbSBlYWdlciB0byBhY2NlcHQKPiBh -bnkgYWx0ZXJuYXRpdmUgc3VnZ2VzdGlvbnMgOi0pCgpBIHRob3VnaHQgb24gdGhhdC4uLiBmcm9t -IGFuIFNvQyBwZXJzcGVjdGl2ZSB0aGVyZSBhcmUgb3RoZXIgaW50ZXJlc3RpbmcgCnBvd2VyIHJh -aWxzIHRoYW4gZ28gdG8ganVzdCB0aGUgQ1BVIGNvcmUuICBGb3IgZXhhbXBsZSBERFIgcG93ZXIg -YW5kIApyYWlscyBpbnZvbHZlZCB3aXRoIG90aGVyIElQIHVuaXRzIG9uIHRoZSBTb0Mgc3VjaCBh -cyAzRCBncmFwaGljcyB1bml0LiAKICBTbyB0eWluZyBvbmUgbnVtYmVyIHRvIHNwZWNpZmljYWxs -eSBhIENQVSBjb3JlIGRvZXMgbm90IHNvdW5kIGxpa2UgCml0J3MgZW5vdWdoLgoKPiA9PT0gT3B0 -aW9uIDI6IGh3bW9uIHBlcmYgUE1VID09PQo+Cj4gQWx0aG91Z2ggdGhlIHRyYWNlIGV2ZW50IG1h -a2VzIGl0IHBvc3NpYmxlIHRvIG9idGFpbiBpbnRlcmVzdGluZwo+IGluZm9ybWF0aW9uIHVzaW5n -IHBlcmYsIHRoZSB1c2VyIHdvdWxkbid0IGJlIGFibGUgdG8gdHJlYXQgdGhlCj4gZW5lcmd5IG1l -dGVyIGFzIGEgbm9ybWFsIGRhdGEgc291cmNlLiBJbiBwYXJ0aWN1bGFyIHRoZXJlIHdvdWxkCj4g -YmUgbm8gd2F5IG9mIGNyZWF0aW5nIGEgZ3JvdXAgb2YgZXZlbnRzIGNvbnNpc3RpbmcgZWcuIG9m -IGEKPiAibm9ybWFsIiBsZWFkZXIgKGVnLiBjYWNoZSBtaXNzIGV2ZW50KSB0cmlnZ2VyaW5nIGVu -ZXJneSBtZXRlcgo+IHJlYWQuIFRoZSBvbmx5IHdheSB0byBnZXQgdGhpcyBkb25lIGlzIHRvIGlt -cGxlbWVudCBhIHBlcmYgUE1VCj4gYmFja2VuZCBwcm92aWRpbmcgImVudmlyb25tZW50YWwgZGF0 -YSIgdG8gdGhlIHVzZXIuCgpJbiB0ZXJtcyBvZiBsaWtlIHBlcmYgdG9wIGRvbid0IHRoaW5rIGl0 -J2xsIGJlIHBvc3NpYmxlIHRvIGtub3cgd2hlbiB0byAKc2FtcGxlIHRoZSBhY3F1aXNpdGlvbiBo -YXJkd2FyZSB0byB0aWUgdGhlIHJlc3VsdCB0byBhIHBhcnRpY3VsYXIgbGluZSAKb2YgY29kZSwg -ZXZlbiBpZiBpdCBoYWQgdGhlIGJhbmR3aWR0aCB0byBkbyB0aGF0LiAgUG93ZXIgcmVhZGluZ3Mg -YXJlIApsaWtlbHkgdG8gbGFnIGFjdGl2aXRpZXMgb24gdGhlIGNwdSBzb21ld2hhdCwgY29uc2lk -ZXJpbmcgc3ViLW5zIGNvcmUgCmNsb2NrcywgZXNwZWNpYWxseSBpZiBpdCdzIGFjdHVhbGx5IG1l -YXN1cmluZyB0aGUgaW5wdXQgc2lkZSBvZiBhIHJlZ3VsYXRvci4KCj4gPSBIaWdoLWxldmVsIGh3 -bW9uIEFQSSBhbmQgUE1VID0KPgo+IEN1cnJlbnQgaHdtb24gc3Vic3lzdGVtIGRvZXMgbm90IHBy -b3ZpZGUgYW55IGFic3RyYWN0aW9uIGZvciB0aGUKPiBtZWFzdXJlZCB2YWx1ZXMgYW5kIHJlcXVp -cmVzIHBhcnRpY3VsYXIgZHJpdmVycyB0byBjcmVhdGUgc3BlY2lmaWVkCj4gc3lzZnMgYXR0cmli -dXRlcyB0aGFuIHVzZWQgYnkgdXNlcnNwYWNlIGxpYnNlbnNvcnMuIFRoaXMgbWFrZXMKPiB0aGUg -ZnJhbWV3b3JrIHVsdGltYXRlbHkgZmxleGlibGUgYW5kIHVsdGltYXRlbHkgaGFyZCB0byBhY2Nl -c3MKPiBmcm9tIHdpdGhpbiB0aGUga2VybmVsLi4uCj4KPiBXaGF0IGNvdWxkIGJlIGRvbmUgaGVy -ZSBpcyBzb21lIChzaW1wbGUpIEFQSSB0byByZWdpc3RlciB0aGUKPiBtZWFzdXJlZCB2YWx1ZXMg -d2l0aCB0aGUgaHdtb24gY29yZSB3aGljaCB3b3VsZCByZXN1bHQgaW4gY3JlYXRpbmcKPiBlcXVp -dmFsZW50IHN5c2ZzIGF0dHJpYnV0ZXMgYXV0b21hZ2ljYWxseSwgYnV0IGFsc28gYWxsb3cgYQo+ -IGluLWtlcm5lbCBBUEkgZm9yIHZhbHVlcyBlbnVtZXJhdGlvbiBhbmQgYWNjZXNzLiBUaGF0IHdh -eSB0aGUgY29yZQo+IGNvdWxkIGFsc28gcmVnaXN0ZXIgYSAiaHdtb24gUE1VIiB3aXRoIHRoZSBw -ZXJmIGZyYW1ld29yayBwcm92aWRpbmcKPiBkYXRhIGZyb20gYWxsICJjb21wbGlhbnQiIGRyaXZl -cnMuCj4KPiA9IEEgZHJpdmVyLXNwZWNpZmljIFBNVSA9Cj4KPiBPZiBjb3Vyc2UgYSBwYXJ0aWN1 -bGFyIGRyaXZlciBjb3VsZCByZWdpc3RlciBpdHMgb3duIHBlcmYgUE1VIG9uIGl0cwo+IG93bi4g -SXQncyBjZXJ0YWlubHkgYW4gb3B0aW9uLCBqdXN0IHZlcnkgc3Vib3B0aW1hbCBpbiBteSBvcGlu -aW9uLgo+IE9yIG1heWJlIG5vdD8gTWF5YmUgdGhlIHRhc2sgaXMgc28gc3BlY2lhbGl6ZWQgdGhh -dCBpdCBtYWtlcyBzZW5zZT8KPgo+Cj4KPiA9PT0gT3B0aW9uIDM6IENQVSBwb3dlcihlbmVyZ3kp -IG1vbml0b3JpbmcgZnJhbWV3b3JrID09PQo+Cj4gQW5kIGxhc3QgYnV0IG5vdCBsZWFzdCwgbWF5 -YmUgdGhlIHByb2JsZW0gZGVzZXJ2ZXMgc29tZSBkZWRpY2F0ZWQKPiBBUEk/IFNvbWV0aGluZyB0 -aGF0IHdvdWxkIHRha2UgcHJvdmlkZXJzIGFuZCBmZWVkIHRoZWlyIGRhdGEgaW50bwo+IGludGVy -ZXN0ZWQgcGFydGllcywgaW4gcGFydGljdWxhciBhIHBlcmYgUE1VIGltcGxlbWVudGF0aW9uIGFu -ZAo+IGNwdWZyZXEgZ292ZXJub3JzPwo+Cj4gTWF5YmUgaXQgY291bGQgYmUgYW4gZXh0ZW5zaW9u -IHRvIHRoZSB0aGVybWFsIGZyYW1ld29yaz8gSXQgYWxyZWFkeQo+IGdpdmVzIHNvbWUgbWVhbmlu -ZyB0byBhIHBoeXNpY2FsIHBoZW5vbWVuYS4gQWRkaW5nIG90aGVyLCByZWxhdGVkIG9uZXMKPiBs -aWtlIGVuZXJneSwgYW5kIHJlbGF0aW5nIGl0IHRvIGNwdSBjb3JlcyBjb3VsZCBtYWtlIHNvbWUg -c2Vuc2UuCgpJZiB5b3UgdHVybiB0aGUgcHJvYmxlbSB1cHNpZGUgZG93biB0byBzb2x2ZSB0aGUg -cmVwcmVzZW50YXRpb24gcXVlc3Rpb24gCmZpcnN0LCBtYXliZSB0aGVyZSdzIGEgd2F5IGZvcndh -cmQgZGVmaW5pbmcgdGhlICJwb3dlciB0cmVlIiBpbiB0ZXJtcyBvZiAKcmVndWxhdG9ycywgYW5k -IHRoZW4gYWRkaW5nIHNvbWV0aGluZyBpbiBzdHJ1Y3QgcmVndWxhdG9yIHRoYXQgc3BhbXMgCnJl -YWRlcnMgd2l0aCB0aW1lc3RhbXBlZCByZXN1bHRzIGlmIHRoZSByZWd1bGF0b3IgaGFzIGEgcG93 -ZXIgbW9uaXRvcmluZyAKY2FwYWJpbGl0eS4KClRoZW4geW91IGNhbiBtYXAgdGhlIHJlZ3VsYXRv -cnMgaW4gdGhlIHBvd2VyIHRyZWUgdG8gcmVhbCBkZXZpY2VzIGJ5IHRoZSAKbmFtZXMgb3IgdGhl -IHN1cHBseSBzdHVmZi4gIEp1c3QgYSB0aG91Z2h0LgoKLUFuZHkKCi0tIApBbmR5IEdyZWVuIHwg -VEkgTGFuZGluZyBUZWFtIExlYWRlcgpMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2Fy -ZSBmb3IgQVJNIFNvQ3MgfCBGb2xsb3cgTGluYXJvCmh0dHA6Ly9mYWNlYm9vay5jb20vcGFnZXMv -TGluYXJvLzE1NTk3NDU4MTA5MTEwNiAgLSAKaHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFyb29y -ZyAtIGh0dHA6Ly9saW5hcm8ub3JnL2xpbmFyby1ibG9nCgpfX19fX19fX19fX19fX19fX19fX19f -X19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5z -b3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xp -c3RpbmZvL2xtLXNlbnNvcnM +On 10/23/12 19:30, the mail apparently from Pawel Moll included: +> Greetings All, +> +> More and more of people are getting interested in the subject of power +> (energy) consumption monitoring. We have some external tools like +> "battery simulators", energy probes etc., but some targets can measure +> their 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. The second +> most frequent request is about providing it to a "energy aware" +> cpufreq governor. +> +> I've came up with three (non-mutually exclusive) options. I will +> appreciate any other ideas and comments (including "it makes not sense +> whatsoever" ones, with justification). Of course I am more than willing +> to spend time on prototyping anything that seems reasonable and propose +> patches. +> +> +> +> === Option 1: Trace event === +> +> This seems to be the "cheapest" option. Simply defining a trace event +> that can be generated by a hwmon (or any other) driver makes the +> interesting data immediately available to any ftrace/perf user. Of +> course it doesn't really help with the cpufreq case, but seems to be +> a good place to start with. +> +> The question is how to define it... I've came up with two prototypes: +> +> = Generic hwmon trace event = +> +> This one allows any driver to generate a trace event whenever any +> "hwmon attribute" (measured value) gets updated. The rate at which the +> updates happen can be controlled by already existing "update_interval" +> attribute. +> +> 8<------------------------------------------- +> TRACE_EVENT(hwmon_attr_update, +> TP_PROTO(struct device *dev, struct attribute *attr, long long input), +> TP_ARGS(dev, attr, input), +> +> TP_STRUCT__entry( +> __string( dev, dev_name(dev)) +> __string( attr, attr->name) +> __field( long long, input) +> ), +> +> TP_fast_assign( +> __assign_str(dev, dev_name(dev)); +> __assign_str(attr, attr->name); +> __entry->input = input; +> ), +> +> TP_printk("%s %s %lld", __get_str(dev), __get_str(attr), __entry->input) +> ); +> 8<------------------------------------------- +> +> It generates such ftrace message: +> +> <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361 +> +> One issue with this is that some external knowledge is required to +> relate a number to a processor core. Or maybe it's not an issue at all +> because it should be left for the user(space)? +> +> = CPU power/energy/temperature trace event = +> +> This one is designed to emphasize the relation between the measured +> value (whether it is energy, temperature or any other physical +> phenomena, really) and CPUs, so it is quite specific (too specific?) +> +> 8<------------------------------------------- +> TRACE_EVENT(cpus_environment, +> TP_PROTO(const struct cpumask *cpus, long long value, char unit), +> TP_ARGS(cpus, value, unit), +> +> TP_STRUCT__entry( +> __array( unsigned char, cpus, sizeof(struct cpumask)) +> __field( long long, value) +> __field( char, unit) +> ), +> +> TP_fast_assign( +> memcpy(__entry->cpus, cpus, sizeof(struct cpumask)); +> __entry->value = value; +> __entry->unit = unit; +> ), +> +> TP_printk("cpus %s %lld[%c]", +> __print_cpumask((struct cpumask *)__entry->cpus), +> __entry->value, __entry->unit) +> ); +> 8<------------------------------------------- +> +> And the equivalent ftrace message is: +> +> <...>127.063107: cpus_environment: cpus 0,1,2,3 34361[C] +> +> It's a cpumask, not just single cpu id, because the sensor may measure +> the value per set of CPUs, eg. a temperature of the whole silicon die +> (so all the cores) or an energy consumed by a subset of cores (this +> is my particular use case - two meters monitor a cluster of two +> processors and a cluster of three processors, all working as a SMP +> system). +> +> Of course the cpus __array could be actually a special __cpumask field +> type (I've just hacked the __print_cpumask so far). And I've just +> realised that the unit field should actually be a string to allow unit +> prefixes to be specified (the above should obviously be "34361[mC]" +> not "[C]"). Also - excuse the "cpus_environment" name - this was the +> best I was able to come up with at the time and I'm eager to accept +> any alternative suggestions :-) + +A thought on that... from an SoC perspective there are other interesting +power rails than go to just the CPU core. For example DDR power and +rails involved with other IP units on the SoC such as 3D graphics unit. + So tying one number to specifically a CPU core does not sound like +it's enough. + +> === Option 2: hwmon perf PMU === +> +> Although the trace event makes it possible to obtain interesting +> information using perf, the user wouldn't be able to treat the +> energy meter as a normal data source. In particular there would +> be no way of creating a group of events consisting eg. of a +> "normal" leader (eg. cache miss event) triggering energy meter +> read. The only way to get this done is to implement a perf PMU +> backend providing "environmental data" to the user. + +In terms of like perf top don't think it'll be possible to know when to +sample the acquisition hardware to tie the result to a particular line +of code, even if it had the bandwidth to do that. Power readings are +likely to lag activities on the cpu somewhat, considering sub-ns core +clocks, especially if it's actually measuring the input side of a regulator. + +> = High-level hwmon API and PMU = +> +> Current hwmon subsystem does not provide any abstraction for the +> measured values and requires particular drivers to create specified +> sysfs attributes than used by userspace libsensors. This makes +> the framework ultimately flexible and ultimately hard to access +> from within the kernel... +> +> What could be done here is some (simple) API to register the +> measured values with the hwmon core which would result in creating +> equivalent sysfs attributes automagically, but also allow a +> in-kernel API for values enumeration and access. That way the core +> could also register a "hwmon PMU" with the perf framework providing +> data from all "compliant" drivers. +> +> = A driver-specific PMU = +> +> 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? +> +> +> +> === Option 3: CPU power(energy) monitoring framework === +> +> And last but not least, maybe the problem deserves some dedicated +> API? Something that would take providers and feed their data into +> interested parties, in particular a perf PMU implementation and +> cpufreq governors? +> +> Maybe it could be an extension to the thermal framework? It already +> gives some meaning to a physical phenomena. Adding other, related ones +> like energy, and relating it to cpu cores could make some sense. + +If you turn the problem upside down to solve the representation question +first, maybe there's a way forward defining the "power tree" in terms of +regulators, and then adding something in struct regulator that spams +readers with timestamped results if the regulator has a power monitoring +capability. + +Then you can map the regulators in the power tree to real devices by the +names or the supply stuff. Just a thought. + +-Andy + +-- +Andy Green | TI Landing Team Leader +Linaro.org │ Open source software for ARM SoCs | Follow Linaro +http://facebook.com/pages/Linaro/155974581091106 - +http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog diff --git a/a/content_digest b/N2/content_digest index 6ff97b4..eb394ec 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,7 +1,7 @@ "ref\01351013449.9070.5.camel@hornet\0" "From\0Andy Green <andy.green@linaro.org>\0" - "Subject\0Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel\0" - "Date\0Tue, 23 Oct 2012 18:49:58 +0000\0" + "Subject\0Re: [RFC] Energy/power monitoring within the kernel\0" + "Date\0Tue, 23 Oct 2012 20:49:58 +0200\0" "To\0Pawel Moll <pawel.moll@arm.com>\0" "Cc\0Amit Daniel Kachhap <amit.kachhap@linaro.org>" Zhang Rui <rui.zhang@intel.com> @@ -21,145 +21,197 @@ " lm-sensors@lm-sensors.org\0" "\00:1\0" "b\0" - "T24gMTAvMjMvMTIgMTk6MzAsIHRoZSBtYWlsIGFwcGFyZW50bHkgZnJvbSBQYXdlbCBNb2xsIGlu\n" - "Y2x1ZGVkOgo+IEdyZWV0aW5ncyBBbGwsCj4KPiBNb3JlIGFuZCBtb3JlIG9mIHBlb3BsZSBhcmUg\n" - "Z2V0dGluZyBpbnRlcmVzdGVkIGluIHRoZSBzdWJqZWN0IG9mIHBvd2VyCj4gKGVuZXJneSkgY29u\n" - "c3VtcHRpb24gbW9uaXRvcmluZy4gV2UgaGF2ZSBzb21lIGV4dGVybmFsIHRvb2xzIGxpa2UKPiAi\n" - "YmF0dGVyeSBzaW11bGF0b3JzIiwgZW5lcmd5IHByb2JlcyBldGMuLCBidXQgc29tZSB0YXJnZXRz\n" - "IGNhbiBtZWFzdXJlCj4gdGhlaXIgcG93ZXIgdXNhZ2Ugb24gdGhlaXIgb3duLgo+Cj4gVHJhZGl0\n" - "aW9uYWxseSBzdWNoIGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIgdmlhIGh3bW9u\n" - "IHN5c2ZzCj4gaW50ZXJmYWNlLCBhbmQgdGhhdCdzIGV4YWN0bHkgd2hhdCBJIGRpZCBmb3IgIm15\n" - "IiBwbGF0Zm9ybSAtIEkgaGF2ZQo+IGEgL3N5cy9jbGFzcy9od21vbi9od21vbiovZGV2aWNlL2Vu\n" - "ZXJneSpfaW5wdXQgYW5kIHRoaXMgd2FzIGdvb2QKPiBlbm91Z2ggdG8gZHJhdyBwcmV0dHkgZ3Jh\n" - "cGhzIGluIHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4KPiBOb3cgSSBhbSBnZXR0\n" - "aW5nIG5ldyByZXF1ZXN0cyB0byBkbyBtb3JlIHdpdGggdGhpcyBkYXRhLiBJbiBwYXJ0aWN1bGFy\n" - "Cj4gSSdtIGFza2VkIGhvdyB0byBhZGQgc3VjaCBpbmZvcm1hdGlvbiB0byBmdHJhY2UvcGVyZiBv\n" - "dXRwdXQuIFRoZSBzZWNvbmQKPiBtb3N0IGZyZXF1ZW50IHJlcXVlc3QgaXMgYWJvdXQgcHJvdmlk\n" - "aW5nIGl0IHRvIGEgImVuZXJneSBhd2FyZSIKPiBjcHVmcmVxIGdvdmVybm9yLgo+Cj4gSSd2ZSBj\n" - "YW1lIHVwIHdpdGggdGhyZWUgKG5vbi1tdXR1YWxseSBleGNsdXNpdmUpIG9wdGlvbnMuIEkgd2ls\n" - "bAo+IGFwcHJlY2lhdGUgYW55IG90aGVyIGlkZWFzIGFuZCBjb21tZW50cyAoaW5jbHVkaW5nICJp\n" - "dCBtYWtlcyBub3Qgc2Vuc2UKPiB3aGF0c29ldmVyIiBvbmVzLCB3aXRoIGp1c3RpZmljYXRpb24p\n" - "LiBPZiBjb3Vyc2UgSSBhbSBtb3JlIHRoYW4gd2lsbGluZwo+IHRvIHNwZW5kIHRpbWUgb24gcHJv\n" - "dG90eXBpbmcgYW55dGhpbmcgdGhhdCBzZWVtcyByZWFzb25hYmxlIGFuZCBwcm9wb3NlCj4gcGF0\n" - "Y2hlcy4KPgo+Cj4KPiA9PT0gT3B0aW9uIDE6IFRyYWNlIGV2ZW50ID09PQo+Cj4gVGhpcyBzZWVt\n" - "cyB0byBiZSB0aGUgImNoZWFwZXN0IiBvcHRpb24uIFNpbXBseSBkZWZpbmluZyBhIHRyYWNlIGV2\n" - "ZW50Cj4gdGhhdCBjYW4gYmUgZ2VuZXJhdGVkIGJ5IGEgaHdtb24gKG9yIGFueSBvdGhlcikgZHJp\n" - "dmVyIG1ha2VzIHRoZQo+IGludGVyZXN0aW5nIGRhdGEgaW1tZWRpYXRlbHkgYXZhaWxhYmxlIHRv\n" - "IGFueSBmdHJhY2UvcGVyZiB1c2VyLiBPZgo+IGNvdXJzZSBpdCBkb2Vzbid0IHJlYWxseSBoZWxw\n" - "IHdpdGggdGhlIGNwdWZyZXEgY2FzZSwgYnV0IHNlZW1zIHRvIGJlCj4gYSBnb29kIHBsYWNlIHRv\n" - "IHN0YXJ0IHdpdGguCj4KPiBUaGUgcXVlc3Rpb24gaXMgaG93IHRvIGRlZmluZSBpdC4uLiBJJ3Zl\n" - "IGNhbWUgdXAgd2l0aCB0d28gcHJvdG90eXBlczoKPgo+ID0gR2VuZXJpYyBod21vbiB0cmFjZSBl\n" - "dmVudCA9Cj4KPiBUaGlzIG9uZSBhbGxvd3MgYW55IGRyaXZlciB0byBnZW5lcmF0ZSBhIHRyYWNl\n" - "IGV2ZW50IHdoZW5ldmVyIGFueQo+ICJod21vbiBhdHRyaWJ1dGUiIChtZWFzdXJlZCB2YWx1ZSkg\n" - "Z2V0cyB1cGRhdGVkLiBUaGUgcmF0ZSBhdCB3aGljaCB0aGUKPiB1cGRhdGVzIGhhcHBlbiBjYW4g\n" - "YmUgY29udHJvbGxlZCBieSBhbHJlYWR5IGV4aXN0aW5nICJ1cGRhdGVfaW50ZXJ2YWwiCj4gYXR0\n" - "cmlidXRlLgo+Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "Cj4gVFJBQ0VfRVZFTlQoaHdtb25fYXR0cl91cGRhdGUsCj4gCVRQX1BST1RPKHN0cnVjdCBkZXZp\n" - "Y2UgKmRldiwgc3RydWN0IGF0dHJpYnV0ZSAqYXR0ciwgbG9uZyBsb25nIGlucHV0KSwKPiAJVFBf\n" - "QVJHUyhkZXYsIGF0dHIsIGlucHV0KSwKPgo+IAlUUF9TVFJVQ1RfX2VudHJ5KAo+IAkJX19zdHJp\n" - "bmcoICAgICAgIGRldiwJCWRldl9uYW1lKGRldikpCj4gCQlfX3N0cmluZygJYXR0ciwJCWF0dHIt\n" - "Pm5hbWUpCj4gCQlfX2ZpZWxkKAlsb25nIGxvbmcsCWlucHV0KQo+IAkpLAo+Cj4gCVRQX2Zhc3Rf\n" - "YXNzaWduKAo+IAkJX19hc3NpZ25fc3RyKGRldiwgZGV2X25hbWUoZGV2KSk7Cj4gCQlfX2Fzc2ln\n" - "bl9zdHIoYXR0ciwgYXR0ci0+bmFtZSk7Cj4gCQlfX2VudHJ5LT5pbnB1dCA9IGlucHV0Owo+IAkp\n" - "LAo+Cj4gCVRQX3ByaW50aygiJXMgJXMgJWxsZCIsIF9fZ2V0X3N0cihkZXYpLCBfX2dldF9zdHIo\n" - "YXR0ciksIF9fZW50cnktPmlucHV0KQo+ICk7Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "LS0tLS0tLS0tLS0tLS0tLS0tCj4KPiBJdCBnZW5lcmF0ZXMgc3VjaCBmdHJhY2UgbWVzc2FnZToK\n" - "Pgo+IDwuLi4+MjEyLjY3MzEyNjogaHdtb25fYXR0cl91cGRhdGU6IGh3bW9uNCB0ZW1wMV9pbnB1\n" - "dCAzNDM2MQo+Cj4gT25lIGlzc3VlIHdpdGggdGhpcyBpcyB0aGF0IHNvbWUgZXh0ZXJuYWwga25v\n" - "d2xlZGdlIGlzIHJlcXVpcmVkIHRvCj4gcmVsYXRlIGEgbnVtYmVyIHRvIGEgcHJvY2Vzc29yIGNv\n" - "cmUuIE9yIG1heWJlIGl0J3Mgbm90IGFuIGlzc3VlIGF0IGFsbAo+IGJlY2F1c2UgaXQgc2hvdWxk\n" - "IGJlIGxlZnQgZm9yIHRoZSB1c2VyKHNwYWNlKT8KPgo+ID0gQ1BVIHBvd2VyL2VuZXJneS90ZW1w\n" - "ZXJhdHVyZSB0cmFjZSBldmVudCA9Cj4KPiBUaGlzIG9uZSBpcyBkZXNpZ25lZCB0byBlbXBoYXNp\n" - "emUgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIG1lYXN1cmVkCj4gdmFsdWUgKHdoZXRoZXIgaXQg\n" - "aXMgZW5lcmd5LCB0ZW1wZXJhdHVyZSBvciBhbnkgb3RoZXIgcGh5c2ljYWwKPiBwaGVub21lbmEs\n" - "IHJlYWxseSkgYW5kIENQVXMsIHNvIGl0IGlzIHF1aXRlIHNwZWNpZmljICh0b28gc3BlY2lmaWM/\n" - "KQo+Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVFJB\n" - "Q0VfRVZFTlQoY3B1c19lbnZpcm9ubWVudCwKPiAJVFBfUFJPVE8oY29uc3Qgc3RydWN0IGNwdW1h\n" - "c2sgKmNwdXMsIGxvbmcgbG9uZyB2YWx1ZSwgY2hhciB1bml0KSwKPiAJVFBfQVJHUyhjcHVzLCB2\n" - "YWx1ZSwgdW5pdCksCj4KPiAJVFBfU1RSVUNUX19lbnRyeSgKPiAJCV9fYXJyYXkoCXVuc2lnbmVk\n" - "IGNoYXIsCWNwdXMsCXNpemVvZihzdHJ1Y3QgY3B1bWFzaykpCj4gCQlfX2ZpZWxkKAlsb25nIGxv\n" - "bmcsCXZhbHVlKQo+IAkJX19maWVsZCgJY2hhciwJCXVuaXQpCj4gCSksCj4KPiAJVFBfZmFzdF9h\n" - "c3NpZ24oCj4gCQltZW1jcHkoX19lbnRyeS0+Y3B1cywgY3B1cywgc2l6ZW9mKHN0cnVjdCBjcHVt\n" - "YXNrKSk7Cj4gCQlfX2VudHJ5LT52YWx1ZSA9IHZhbHVlOwo+IAkJX19lbnRyeS0+dW5pdCA9IHVu\n" - "aXQ7Cj4gCSksCj4KPiAJVFBfcHJpbnRrKCJjcHVzICVzICVsbGRbJWNdIiwKPiAJCV9fcHJpbnRf\n" - "Y3B1bWFzaygoc3RydWN0IGNwdW1hc2sgKilfX2VudHJ5LT5jcHVzKSwKPiAJCV9fZW50cnktPnZh\n" - "bHVlLCBfX2VudHJ5LT51bml0KQo+ICk7Cj4gODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "LS0tLS0tLS0tLS0tLS0tCj4KPiBBbmQgdGhlIGVxdWl2YWxlbnQgZnRyYWNlIG1lc3NhZ2UgaXM6\n" - "Cj4KPiA8Li4uPjEyNy4wNjMxMDc6IGNwdXNfZW52aXJvbm1lbnQ6IGNwdXMgMCwxLDIsMyAzNDM2\n" - "MVtDXQo+Cj4gSXQncyBhIGNwdW1hc2ssIG5vdCBqdXN0IHNpbmdsZSBjcHUgaWQsIGJlY2F1c2Ug\n" - "dGhlIHNlbnNvciBtYXkgbWVhc3VyZQo+IHRoZSB2YWx1ZSBwZXIgc2V0IG9mIENQVXMsIGVnLiBh\n" - "IHRlbXBlcmF0dXJlIG9mIHRoZSB3aG9sZSBzaWxpY29uIGRpZQo+IChzbyBhbGwgdGhlIGNvcmVz\n" - "KSBvciBhbiBlbmVyZ3kgY29uc3VtZWQgYnkgYSBzdWJzZXQgb2YgY29yZXMgKHRoaXMKPiBpcyBt\n" - "eSBwYXJ0aWN1bGFyIHVzZSBjYXNlIC0gdHdvIG1ldGVycyBtb25pdG9yIGEgY2x1c3RlciBvZiB0\n" - "d28KPiBwcm9jZXNzb3JzIGFuZCBhIGNsdXN0ZXIgb2YgdGhyZWUgcHJvY2Vzc29ycywgYWxsIHdv\n" - "cmtpbmcgYXMgYSBTTVAKPiBzeXN0ZW0pLgo+Cj4gT2YgY291cnNlIHRoZSBjcHVzIF9fYXJyYXkg\n" - "Y291bGQgYmUgYWN0dWFsbHkgYSBzcGVjaWFsIF9fY3B1bWFzayBmaWVsZAo+IHR5cGUgKEkndmUg\n" - "anVzdCBoYWNrZWQgdGhlIF9fcHJpbnRfY3B1bWFzayBzbyBmYXIpLiBBbmQgSSd2ZSBqdXN0Cj4g\n" - "cmVhbGlzZWQgdGhhdCB0aGUgdW5pdCBmaWVsZCBzaG91bGQgYWN0dWFsbHkgYmUgYSBzdHJpbmcg\n" - "dG8gYWxsb3cgdW5pdAo+IHByZWZpeGVzIHRvIGJlIHNwZWNpZmllZCAodGhlIGFib3ZlIHNob3Vs\n" - "ZCBvYnZpb3VzbHkgYmUgIjM0MzYxW21DXSIKPiBub3QgIltDXSIpLiBBbHNvIC0gZXhjdXNlIHRo\n" - "ZSAiY3B1c19lbnZpcm9ubWVudCIgbmFtZSAtIHRoaXMgd2FzIHRoZQo+IGJlc3QgSSB3YXMgYWJs\n" - "ZSB0byBjb21lIHVwIHdpdGggYXQgdGhlIHRpbWUgYW5kIEknbSBlYWdlciB0byBhY2NlcHQKPiBh\n" - "bnkgYWx0ZXJuYXRpdmUgc3VnZ2VzdGlvbnMgOi0pCgpBIHRob3VnaHQgb24gdGhhdC4uLiBmcm9t\n" - "IGFuIFNvQyBwZXJzcGVjdGl2ZSB0aGVyZSBhcmUgb3RoZXIgaW50ZXJlc3RpbmcgCnBvd2VyIHJh\n" - "aWxzIHRoYW4gZ28gdG8ganVzdCB0aGUgQ1BVIGNvcmUuICBGb3IgZXhhbXBsZSBERFIgcG93ZXIg\n" - "YW5kIApyYWlscyBpbnZvbHZlZCB3aXRoIG90aGVyIElQIHVuaXRzIG9uIHRoZSBTb0Mgc3VjaCBh\n" - "cyAzRCBncmFwaGljcyB1bml0LiAKICBTbyB0eWluZyBvbmUgbnVtYmVyIHRvIHNwZWNpZmljYWxs\n" - "eSBhIENQVSBjb3JlIGRvZXMgbm90IHNvdW5kIGxpa2UgCml0J3MgZW5vdWdoLgoKPiA9PT0gT3B0\n" - "aW9uIDI6IGh3bW9uIHBlcmYgUE1VID09PQo+Cj4gQWx0aG91Z2ggdGhlIHRyYWNlIGV2ZW50IG1h\n" - "a2VzIGl0IHBvc3NpYmxlIHRvIG9idGFpbiBpbnRlcmVzdGluZwo+IGluZm9ybWF0aW9uIHVzaW5n\n" - "IHBlcmYsIHRoZSB1c2VyIHdvdWxkbid0IGJlIGFibGUgdG8gdHJlYXQgdGhlCj4gZW5lcmd5IG1l\n" - "dGVyIGFzIGEgbm9ybWFsIGRhdGEgc291cmNlLiBJbiBwYXJ0aWN1bGFyIHRoZXJlIHdvdWxkCj4g\n" - "YmUgbm8gd2F5IG9mIGNyZWF0aW5nIGEgZ3JvdXAgb2YgZXZlbnRzIGNvbnNpc3RpbmcgZWcuIG9m\n" - "IGEKPiAibm9ybWFsIiBsZWFkZXIgKGVnLiBjYWNoZSBtaXNzIGV2ZW50KSB0cmlnZ2VyaW5nIGVu\n" - "ZXJneSBtZXRlcgo+IHJlYWQuIFRoZSBvbmx5IHdheSB0byBnZXQgdGhpcyBkb25lIGlzIHRvIGlt\n" - "cGxlbWVudCBhIHBlcmYgUE1VCj4gYmFja2VuZCBwcm92aWRpbmcgImVudmlyb25tZW50YWwgZGF0\n" - "YSIgdG8gdGhlIHVzZXIuCgpJbiB0ZXJtcyBvZiBsaWtlIHBlcmYgdG9wIGRvbid0IHRoaW5rIGl0\n" - "J2xsIGJlIHBvc3NpYmxlIHRvIGtub3cgd2hlbiB0byAKc2FtcGxlIHRoZSBhY3F1aXNpdGlvbiBo\n" - "YXJkd2FyZSB0byB0aWUgdGhlIHJlc3VsdCB0byBhIHBhcnRpY3VsYXIgbGluZSAKb2YgY29kZSwg\n" - "ZXZlbiBpZiBpdCBoYWQgdGhlIGJhbmR3aWR0aCB0byBkbyB0aGF0LiAgUG93ZXIgcmVhZGluZ3Mg\n" - "YXJlIApsaWtlbHkgdG8gbGFnIGFjdGl2aXRpZXMgb24gdGhlIGNwdSBzb21ld2hhdCwgY29uc2lk\n" - "ZXJpbmcgc3ViLW5zIGNvcmUgCmNsb2NrcywgZXNwZWNpYWxseSBpZiBpdCdzIGFjdHVhbGx5IG1l\n" - "YXN1cmluZyB0aGUgaW5wdXQgc2lkZSBvZiBhIHJlZ3VsYXRvci4KCj4gPSBIaWdoLWxldmVsIGh3\n" - "bW9uIEFQSSBhbmQgUE1VID0KPgo+IEN1cnJlbnQgaHdtb24gc3Vic3lzdGVtIGRvZXMgbm90IHBy\n" - "b3ZpZGUgYW55IGFic3RyYWN0aW9uIGZvciB0aGUKPiBtZWFzdXJlZCB2YWx1ZXMgYW5kIHJlcXVp\n" - "cmVzIHBhcnRpY3VsYXIgZHJpdmVycyB0byBjcmVhdGUgc3BlY2lmaWVkCj4gc3lzZnMgYXR0cmli\n" - "dXRlcyB0aGFuIHVzZWQgYnkgdXNlcnNwYWNlIGxpYnNlbnNvcnMuIFRoaXMgbWFrZXMKPiB0aGUg\n" - "ZnJhbWV3b3JrIHVsdGltYXRlbHkgZmxleGlibGUgYW5kIHVsdGltYXRlbHkgaGFyZCB0byBhY2Nl\n" - "c3MKPiBmcm9tIHdpdGhpbiB0aGUga2VybmVsLi4uCj4KPiBXaGF0IGNvdWxkIGJlIGRvbmUgaGVy\n" - "ZSBpcyBzb21lIChzaW1wbGUpIEFQSSB0byByZWdpc3RlciB0aGUKPiBtZWFzdXJlZCB2YWx1ZXMg\n" - "d2l0aCB0aGUgaHdtb24gY29yZSB3aGljaCB3b3VsZCByZXN1bHQgaW4gY3JlYXRpbmcKPiBlcXVp\n" - "dmFsZW50IHN5c2ZzIGF0dHJpYnV0ZXMgYXV0b21hZ2ljYWxseSwgYnV0IGFsc28gYWxsb3cgYQo+\n" - "IGluLWtlcm5lbCBBUEkgZm9yIHZhbHVlcyBlbnVtZXJhdGlvbiBhbmQgYWNjZXNzLiBUaGF0IHdh\n" - "eSB0aGUgY29yZQo+IGNvdWxkIGFsc28gcmVnaXN0ZXIgYSAiaHdtb24gUE1VIiB3aXRoIHRoZSBw\n" - "ZXJmIGZyYW1ld29yayBwcm92aWRpbmcKPiBkYXRhIGZyb20gYWxsICJjb21wbGlhbnQiIGRyaXZl\n" - "cnMuCj4KPiA9IEEgZHJpdmVyLXNwZWNpZmljIFBNVSA9Cj4KPiBPZiBjb3Vyc2UgYSBwYXJ0aWN1\n" - "bGFyIGRyaXZlciBjb3VsZCByZWdpc3RlciBpdHMgb3duIHBlcmYgUE1VIG9uIGl0cwo+IG93bi4g\n" - "SXQncyBjZXJ0YWlubHkgYW4gb3B0aW9uLCBqdXN0IHZlcnkgc3Vib3B0aW1hbCBpbiBteSBvcGlu\n" - "aW9uLgo+IE9yIG1heWJlIG5vdD8gTWF5YmUgdGhlIHRhc2sgaXMgc28gc3BlY2lhbGl6ZWQgdGhh\n" - "dCBpdCBtYWtlcyBzZW5zZT8KPgo+Cj4KPiA9PT0gT3B0aW9uIDM6IENQVSBwb3dlcihlbmVyZ3kp\n" - "IG1vbml0b3JpbmcgZnJhbWV3b3JrID09PQo+Cj4gQW5kIGxhc3QgYnV0IG5vdCBsZWFzdCwgbWF5\n" - "YmUgdGhlIHByb2JsZW0gZGVzZXJ2ZXMgc29tZSBkZWRpY2F0ZWQKPiBBUEk/IFNvbWV0aGluZyB0\n" - "aGF0IHdvdWxkIHRha2UgcHJvdmlkZXJzIGFuZCBmZWVkIHRoZWlyIGRhdGEgaW50bwo+IGludGVy\n" - "ZXN0ZWQgcGFydGllcywgaW4gcGFydGljdWxhciBhIHBlcmYgUE1VIGltcGxlbWVudGF0aW9uIGFu\n" - "ZAo+IGNwdWZyZXEgZ292ZXJub3JzPwo+Cj4gTWF5YmUgaXQgY291bGQgYmUgYW4gZXh0ZW5zaW9u\n" - "IHRvIHRoZSB0aGVybWFsIGZyYW1ld29yaz8gSXQgYWxyZWFkeQo+IGdpdmVzIHNvbWUgbWVhbmlu\n" - "ZyB0byBhIHBoeXNpY2FsIHBoZW5vbWVuYS4gQWRkaW5nIG90aGVyLCByZWxhdGVkIG9uZXMKPiBs\n" - "aWtlIGVuZXJneSwgYW5kIHJlbGF0aW5nIGl0IHRvIGNwdSBjb3JlcyBjb3VsZCBtYWtlIHNvbWUg\n" - "c2Vuc2UuCgpJZiB5b3UgdHVybiB0aGUgcHJvYmxlbSB1cHNpZGUgZG93biB0byBzb2x2ZSB0aGUg\n" - "cmVwcmVzZW50YXRpb24gcXVlc3Rpb24gCmZpcnN0LCBtYXliZSB0aGVyZSdzIGEgd2F5IGZvcndh\n" - "cmQgZGVmaW5pbmcgdGhlICJwb3dlciB0cmVlIiBpbiB0ZXJtcyBvZiAKcmVndWxhdG9ycywgYW5k\n" - "IHRoZW4gYWRkaW5nIHNvbWV0aGluZyBpbiBzdHJ1Y3QgcmVndWxhdG9yIHRoYXQgc3BhbXMgCnJl\n" - "YWRlcnMgd2l0aCB0aW1lc3RhbXBlZCByZXN1bHRzIGlmIHRoZSByZWd1bGF0b3IgaGFzIGEgcG93\n" - "ZXIgbW9uaXRvcmluZyAKY2FwYWJpbGl0eS4KClRoZW4geW91IGNhbiBtYXAgdGhlIHJlZ3VsYXRv\n" - "cnMgaW4gdGhlIHBvd2VyIHRyZWUgdG8gcmVhbCBkZXZpY2VzIGJ5IHRoZSAKbmFtZXMgb3IgdGhl\n" - "IHN1cHBseSBzdHVmZi4gIEp1c3QgYSB0aG91Z2h0LgoKLUFuZHkKCi0tIApBbmR5IEdyZWVuIHwg\n" - "VEkgTGFuZGluZyBUZWFtIExlYWRlcgpMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2Fy\n" - "ZSBmb3IgQVJNIFNvQ3MgfCBGb2xsb3cgTGluYXJvCmh0dHA6Ly9mYWNlYm9vay5jb20vcGFnZXMv\n" - "TGluYXJvLzE1NTk3NDU4MTA5MTEwNiAgLSAKaHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFyb29y\n" - "ZyAtIGh0dHA6Ly9saW5hcm8ub3JnL2xpbmFyby1ibG9nCgpfX19fX19fX19fX19fX19fX19fX19f\n" - "X19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5z\n" - "b3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xp\n" - c3RpbmZvL2xtLXNlbnNvcnM + "On 10/23/12 19:30, the mail apparently from Pawel Moll included:\n" + "> Greetings All,\n" + ">\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. The second\n" + "> most frequent request is about providing it to a \"energy aware\"\n" + "> cpufreq governor.\n" + ">\n" + "> I've came up with three (non-mutually exclusive) options. I will\n" + "> appreciate any other ideas and comments (including \"it makes not sense\n" + "> whatsoever\" ones, with justification). Of course I am more than willing\n" + "> to spend time on prototyping anything that seems reasonable and propose\n" + "> patches.\n" + ">\n" + ">\n" + ">\n" + "> === Option 1: Trace event ===\n" + ">\n" + "> This seems to be the \"cheapest\" option. Simply defining a trace event\n" + "> that can be generated by a hwmon (or any other) driver makes the\n" + "> interesting data immediately available to any ftrace/perf user. Of\n" + "> course it doesn't really help with the cpufreq case, but seems to be\n" + "> a good place to start with.\n" + ">\n" + "> The question is how to define it... I've came up with two prototypes:\n" + ">\n" + "> = Generic hwmon trace event =\n" + ">\n" + "> This one allows any driver to generate a trace event whenever any\n" + "> \"hwmon attribute\" (measured value) gets updated. The rate at which the\n" + "> updates happen can be controlled by already existing \"update_interval\"\n" + "> attribute.\n" + ">\n" + "> 8<-------------------------------------------\n" + "> TRACE_EVENT(hwmon_attr_update,\n" + "> \tTP_PROTO(struct device *dev, struct attribute *attr, long long input),\n" + "> \tTP_ARGS(dev, attr, input),\n" + ">\n" + "> \tTP_STRUCT__entry(\n" + "> \t\t__string( dev,\t\tdev_name(dev))\n" + "> \t\t__string(\tattr,\t\tattr->name)\n" + "> \t\t__field(\tlong long,\tinput)\n" + "> \t),\n" + ">\n" + "> \tTP_fast_assign(\n" + "> \t\t__assign_str(dev, dev_name(dev));\n" + "> \t\t__assign_str(attr, attr->name);\n" + "> \t\t__entry->input = input;\n" + "> \t),\n" + ">\n" + "> \tTP_printk(\"%s %s %lld\", __get_str(dev), __get_str(attr), __entry->input)\n" + "> );\n" + "> 8<-------------------------------------------\n" + ">\n" + "> It generates such ftrace message:\n" + ">\n" + "> <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361\n" + ">\n" + "> One issue with this is that some external knowledge is required to\n" + "> relate a number to a processor core. Or maybe it's not an issue at all\n" + "> because it should be left for the user(space)?\n" + ">\n" + "> = CPU power/energy/temperature trace event =\n" + ">\n" + "> This one is designed to emphasize the relation between the measured\n" + "> value (whether it is energy, temperature or any other physical\n" + "> phenomena, really) and CPUs, so it is quite specific (too specific?)\n" + ">\n" + "> 8<-------------------------------------------\n" + "> TRACE_EVENT(cpus_environment,\n" + "> \tTP_PROTO(const struct cpumask *cpus, long long value, char unit),\n" + "> \tTP_ARGS(cpus, value, unit),\n" + ">\n" + "> \tTP_STRUCT__entry(\n" + "> \t\t__array(\tunsigned char,\tcpus,\tsizeof(struct cpumask))\n" + "> \t\t__field(\tlong long,\tvalue)\n" + "> \t\t__field(\tchar,\t\tunit)\n" + "> \t),\n" + ">\n" + "> \tTP_fast_assign(\n" + "> \t\tmemcpy(__entry->cpus, cpus, sizeof(struct cpumask));\n" + "> \t\t__entry->value = value;\n" + "> \t\t__entry->unit = unit;\n" + "> \t),\n" + ">\n" + "> \tTP_printk(\"cpus %s %lld[%c]\",\n" + "> \t\t__print_cpumask((struct cpumask *)__entry->cpus),\n" + "> \t\t__entry->value, __entry->unit)\n" + "> );\n" + "> 8<-------------------------------------------\n" + ">\n" + "> And the equivalent ftrace message is:\n" + ">\n" + "> <...>127.063107: cpus_environment: cpus 0,1,2,3 34361[C]\n" + ">\n" + "> It's a cpumask, not just single cpu id, because the sensor may measure\n" + "> the value per set of CPUs, eg. a temperature of the whole silicon die\n" + "> (so all the cores) or an energy consumed by a subset of cores (this\n" + "> is my particular use case - two meters monitor a cluster of two\n" + "> processors and a cluster of three processors, all working as a SMP\n" + "> system).\n" + ">\n" + "> Of course the cpus __array could be actually a special __cpumask field\n" + "> type (I've just hacked the __print_cpumask so far). And I've just\n" + "> realised that the unit field should actually be a string to allow unit\n" + "> prefixes to be specified (the above should obviously be \"34361[mC]\"\n" + "> not \"[C]\"). Also - excuse the \"cpus_environment\" name - this was the\n" + "> best I was able to come up with at the time and I'm eager to accept\n" + "> any alternative suggestions :-)\n" + "\n" + "A thought on that... from an SoC perspective there are other interesting \n" + "power rails than go to just the CPU core. For example DDR power and \n" + "rails involved with other IP units on the SoC such as 3D graphics unit. \n" + " So tying one number to specifically a CPU core does not sound like \n" + "it's enough.\n" + "\n" + "> === Option 2: hwmon perf PMU ===\n" + ">\n" + "> Although the trace event makes it possible to obtain interesting\n" + "> information using perf, the user wouldn't be able to treat the\n" + "> energy meter as a normal data source. In particular there would\n" + "> be no way of creating a group of events consisting eg. of a\n" + "> \"normal\" leader (eg. cache miss event) triggering energy meter\n" + "> read. The only way to get this done is to implement a perf PMU\n" + "> backend providing \"environmental data\" to the user.\n" + "\n" + "In terms of like perf top don't think it'll be possible to know when to \n" + "sample the acquisition hardware to tie the result to a particular line \n" + "of code, even if it had the bandwidth to do that. Power readings are \n" + "likely to lag activities on the cpu somewhat, considering sub-ns core \n" + "clocks, especially if it's actually measuring the input side of a regulator.\n" + "\n" + "> = High-level hwmon API and PMU =\n" + ">\n" + "> Current hwmon subsystem does not provide any abstraction for the\n" + "> measured values and requires particular drivers to create specified\n" + "> sysfs attributes than used by userspace libsensors. This makes\n" + "> the framework ultimately flexible and ultimately hard to access\n" + "> from within the kernel...\n" + ">\n" + "> What could be done here is some (simple) API to register the\n" + "> measured values with the hwmon core which would result in creating\n" + "> equivalent sysfs attributes automagically, but also allow a\n" + "> in-kernel API for values enumeration and access. That way the core\n" + "> could also register a \"hwmon PMU\" with the perf framework providing\n" + "> data from all \"compliant\" drivers.\n" + ">\n" + "> = A driver-specific PMU =\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" + ">\n" + ">\n" + "> === Option 3: CPU power(energy) monitoring framework ===\n" + ">\n" + "> And last but not least, maybe the problem deserves some dedicated\n" + "> API? Something that would take providers and feed their data into\n" + "> interested parties, in particular a perf PMU implementation and\n" + "> cpufreq governors?\n" + ">\n" + "> Maybe it could be an extension to the thermal framework? It already\n" + "> gives some meaning to a physical phenomena. Adding other, related ones\n" + "> like energy, and relating it to cpu cores could make some sense.\n" + "\n" + "If you turn the problem upside down to solve the representation question \n" + "first, maybe there's a way forward defining the \"power tree\" in terms of \n" + "regulators, and then adding something in struct regulator that spams \n" + "readers with timestamped results if the regulator has a power monitoring \n" + "capability.\n" + "\n" + "Then you can map the regulators in the power tree to real devices by the \n" + "names or the supply stuff. Just a thought.\n" + "\n" + "-Andy\n" + "\n" + "-- \n" + "Andy Green | TI Landing Team Leader\n" + "Linaro.org \342\224\202 Open source software for ARM SoCs | Follow Linaro\n" + "http://facebook.com/pages/Linaro/155974581091106 - \n" + http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog -22232a0f12680e64197ada3f65b77e0155a7c984437b3814dc404f223114fb98 +0d54d0977dd0515f39b2319267f68e955baf82120a31a90d10fcb752fea5ce8e
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.