From: Andy Green <andy.green@linaro.org>
To: Pawel Moll <pawel.moll@arm.com>
Cc: Amit Daniel Kachhap <amit.kachhap@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Jean Delvare <khali@linux-fr.org>,
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
Subject: Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel
Date: Tue, 23 Oct 2012 18:49:58 +0000 [thread overview]
Message-ID: <5086E6D6.8000208@linaro.org> (raw)
In-Reply-To: <1351013449.9070.5.camel@hornet>
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
WARNING: multiple messages have this Message-ID (diff)
From: andy.green@linaro.org (Andy Green)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] Energy/power monitoring within the kernel
Date: Tue, 23 Oct 2012 20:49:58 +0200 [thread overview]
Message-ID: <5086E6D6.8000208@linaro.org> (raw)
In-Reply-To: <1351013449.9070.5.camel@hornet>
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
WARNING: multiple messages have this Message-ID (diff)
From: Andy Green <andy.green@linaro.org>
To: Pawel Moll <pawel.moll@arm.com>
Cc: Amit Daniel Kachhap <amit.kachhap@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Jean Delvare <khali@linux-fr.org>,
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
Subject: Re: [RFC] Energy/power monitoring within the kernel
Date: Tue, 23 Oct 2012 20:49:58 +0200 [thread overview]
Message-ID: <5086E6D6.8000208@linaro.org> (raw)
In-Reply-To: <1351013449.9070.5.camel@hornet>
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
next prev parent reply other threads:[~2012-10-23 18:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 17:30 [lm-sensors] [RFC] Energy/power monitoring within the kernel Pawel Moll
2012-10-23 17:30 ` Pawel Moll
2012-10-23 17:30 ` Pawel Moll
2012-10-23 17:43 ` [lm-sensors] " Steven Rostedt
2012-10-23 17:43 ` Steven Rostedt
2012-10-23 17:43 ` Steven Rostedt
2012-10-24 16:00 ` [lm-sensors] " Pawel Moll
2012-10-24 16:00 ` Pawel Moll
2012-10-24 16:00 ` Pawel Moll
2012-10-23 18:49 ` Andy Green [this message]
2012-10-23 18:49 ` Andy Green
2012-10-23 18:49 ` Andy Green
2012-10-24 16:05 ` [lm-sensors] " Pawel Moll
2012-10-24 16:05 ` Pawel Moll
2012-10-24 16:05 ` Pawel Moll
2012-10-23 22:02 ` [lm-sensors] " Guenter Roeck
2012-10-23 22:02 ` Guenter Roeck
2012-10-23 22:02 ` Guenter Roeck
2012-10-24 16:37 ` [lm-sensors] " Pawel Moll
2012-10-24 16:37 ` Pawel Moll
2012-10-24 16:37 ` Pawel Moll
2012-10-24 20:01 ` [lm-sensors] " Guenter Roeck
2012-10-24 20:01 ` Guenter Roeck
2012-10-24 20:01 ` Guenter Roeck
2012-10-24 0:40 ` [lm-sensors] " Thomas Renninger
2012-10-24 0:40 ` Thomas Renninger
2012-10-24 0:40 ` Thomas Renninger
2012-10-24 16:51 ` [lm-sensors] " Pawel Moll
2012-10-24 16:51 ` Pawel Moll
2012-10-24 16:51 ` Pawel Moll
2012-10-24 0:41 ` [lm-sensors] " Thomas Renninger
2012-10-24 0:41 ` Thomas Renninger
2012-10-24 0:41 ` Thomas Renninger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5086E6D6.8000208@linaro.org \
--to=andy.green@linaro.org \
--cc=amit.kachhap@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=fweisbec@gmail.com \
--cc=jean.pihet@newoldbits.com \
--cc=jj@chaosbits.net \
--cc=khali@linux-fr.org \
--cc=linaro-dev@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
--cc=mingo@elte.hu \
--cc=pawel.moll@arm.com \
--cc=rostedt@goodmis.org \
--cc=rui.zhang@intel.com \
--cc=trenn@suse.de \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.