From: Pawel Moll <pawel.moll@arm.com>
To: Andy Green <andy.green@linaro.org>
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" <linaro-dev@lists.linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>
Subject: Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel
Date: Wed, 24 Oct 2012 16:05:11 +0000 [thread overview]
Message-ID: <1351094711.23327.47.camel@hornet> (raw)
In-Reply-To: <5086E6D6.8000208@linaro.org>
T24gVHVlLCAyMDEyLTEwLTIzIGF0IDE5OjQ5ICswMTAwLCBBbmR5IEdyZWVuIHdyb3RlOgo+IEEg
dGhvdWdodCBvbiB0aGF0Li4uIGZyb20gYW4gU29DIHBlcnNwZWN0aXZlIHRoZXJlIGFyZSBvdGhl
ciBpbnRlcmVzdGluZyAKPiBwb3dlciByYWlscyB0aGFuIGdvIHRvIGp1c3QgdGhlIENQVSBjb3Jl
LiAgRm9yIGV4YW1wbGUgRERSIHBvd2VyIGFuZCAKPiByYWlscyBpbnZvbHZlZCB3aXRoIG90aGVy
IElQIHVuaXRzIG9uIHRoZSBTb0Mgc3VjaCBhcyAzRCBncmFwaGljcyB1bml0LiAKPiAgIFNvIHR5
aW5nIG9uZSBudW1iZXIgdG8gc3BlY2lmaWNhbGx5IGEgQ1BVIGNvcmUgZG9lcyBub3Qgc291bmQg
bGlrZSAKPiBpdCdzIGVub3VnaC4KCkkgZG8gcmVhbGl6ZSB0aGlzLiBJIGp1c3QgZGlkbid0IHdh
bnQgdG8gdHJ5IHRvIGNvdmVyIHRvbyBtdWNoIGdyb3VuZCwKYW5kIGNwdWZyZXEgZ292ZXJub3Ig
d291bGQgYmUgaW50ZXJlc3RlZCBpbiBjcHUtcmVsYXRlZCBkYXRhIGFueXdheS4uLgoKPiBJZiB5
b3UgdHVybiB0aGUgcHJvYmxlbSB1cHNpZGUgZG93biB0byBzb2x2ZSB0aGUgcmVwcmVzZW50YXRp
b24gcXVlc3Rpb24gCj4gZmlyc3QsIG1heWJlIHRoZXJlJ3MgYSB3YXkgZm9yd2FyZCBkZWZpbmlu
ZyB0aGUgInBvd2VyIHRyZWUiIGluIHRlcm1zIG9mIAo+IHJlZ3VsYXRvcnMsIGFuZCB0aGVuIGFk
ZGluZyBzb21ldGhpbmcgaW4gc3RydWN0IHJlZ3VsYXRvciB0aGF0IHNwYW1zIAo+IHJlYWRlcnMg
d2l0aCB0aW1lc3RhbXBlZCByZXN1bHRzIGlmIHRoZSByZWd1bGF0b3IgaGFzIGEgcG93ZXIgbW9u
aXRvcmluZyAKPiBjYXBhYmlsaXR5Lgo+IAo+IFRoZW4geW91IGNhbiBtYXAgdGhlIHJlZ3VsYXRv
cnMgaW4gdGhlIHBvd2VyIHRyZWUgdG8gcmVhbCBkZXZpY2VzIGJ5IHRoZSAKPiBuYW1lcyBvciB0
aGUgc3VwcGx5IHN0dWZmLiAgSnVzdCBhIHRob3VnaHQuCgpIbS4gSW50ZXJlc3RpbmcgaWRlYSBp
bmRlZWQgLSBpZiBhIHJlZ3VsYXRvciBkZXZpY2Ugd2FzIGFibGUgdG8gcmVwb3J0CnRoZSBlbmVy
Z3kgYmVpbmcgcHJvZHVjZWQgYnkgaXQgKGluc3RlYWQgb2YgbG9va2luZyBhdCBjdW11bGF0aXZl
IGVuZXJneQpjb25zdW1lZCBieSBtb3JlIHRoYW4gb25lIGRldmljZSksIGRlZmluaW5nICJwb3dl
ciBkb21haW5zIiAoYnkgYWRkaW5nCnNlbGVjdGVkIGNwdXMgYXMgY29uc3VtZXJzKSB3b3VsZCBi
ZSBzdHJhaWdodCBmb3J3YXJkIGFuZCB0aGUgY3B1ZnJlcQpjb3VsZCByZXF1ZXN0IHRoZSBpbmZv
cm1hdGlvbiB0aGF0IHdheS4KCkknbGwgbG9vayBpbnRvIGl0LCB0aGFua3MhCgpQYXdlxYIKCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29y
cyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0t
c2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz
WARNING: multiple messages have this Message-ID (diff)
From: pawel.moll@arm.com (Pawel Moll)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] Energy/power monitoring within the kernel
Date: Wed, 24 Oct 2012 17:05:11 +0100 [thread overview]
Message-ID: <1351094711.23327.47.camel@hornet> (raw)
In-Reply-To: <5086E6D6.8000208@linaro.org>
On Tue, 2012-10-23 at 19:49 +0100, Andy Green wrote:
> 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.
I do realize this. I just didn't want to try to cover too much ground,
and cpufreq governor would be interested in cpu-related data anyway...
> 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.
Hm. Interesting idea indeed - if a regulator device was able to report
the energy being produced by it (instead of looking at cumulative energy
consumed by more than one device), defining "power domains" (by adding
selected cpus as consumers) would be straight forward and the cpufreq
could request the information that way.
I'll look into it, thanks!
Pawe?
WARNING: multiple messages have this Message-ID (diff)
From: Pawel Moll <pawel.moll@arm.com>
To: Andy Green <andy.green@linaro.org>
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" <linaro-dev@lists.linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>
Subject: Re: [RFC] Energy/power monitoring within the kernel
Date: Wed, 24 Oct 2012 17:05:11 +0100 [thread overview]
Message-ID: <1351094711.23327.47.camel@hornet> (raw)
In-Reply-To: <5086E6D6.8000208@linaro.org>
On Tue, 2012-10-23 at 19:49 +0100, Andy Green wrote:
> 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.
I do realize this. I just didn't want to try to cover too much ground,
and cpufreq governor would be interested in cpu-related data anyway...
> 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.
Hm. Interesting idea indeed - if a regulator device was able to report
the energy being produced by it (instead of looking at cumulative energy
consumed by more than one device), defining "power domains" (by adding
selected cpus as consumers) would be straight forward and the cpufreq
could request the information that way.
I'll look into it, thanks!
Paweł
next prev parent reply other threads:[~2012-10-24 16:05 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 17:30 [lm-sensors] [RFC] Energy/power monitoring within the kernel Pawel Moll
2012-10-23 17:30 ` Pawel Moll
2012-10-23 17:30 ` Pawel Moll
2012-10-23 17:43 ` [lm-sensors] " Steven Rostedt
2012-10-23 17:43 ` Steven Rostedt
2012-10-23 17:43 ` Steven Rostedt
2012-10-24 16:00 ` [lm-sensors] " Pawel Moll
2012-10-24 16:00 ` Pawel Moll
2012-10-24 16:00 ` Pawel Moll
2012-10-23 18:49 ` [lm-sensors] " Andy Green
2012-10-23 18:49 ` Andy Green
2012-10-23 18:49 ` Andy Green
2012-10-24 16:05 ` Pawel Moll [this message]
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=1351094711.23327.47.camel@hornet \
--to=pawel.moll@arm.com \
--cc=amit.kachhap@linaro.org \
--cc=andy.green@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=fweisbec@gmail.com \
--cc=jean.pihet@newoldbits.com \
--cc=jj@chaosbits.net \
--cc=khali@linux-fr.org \
--cc=linaro-dev@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=rui.zhang@intel.com \
--cc=trenn@suse.de \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.