From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934350Ab2JXQFT (ORCPT ); Wed, 24 Oct 2012 12:05:19 -0400 Received: from service87.mimecast.com ([91.220.42.44]:43060 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932280Ab2JXQFQ convert rfc822-to-8bit (ORCPT ); Wed, 24 Oct 2012 12:05:16 -0400 Message-ID: <1351094711.23327.47.camel@hornet> Subject: Re: [RFC] Energy/power monitoring within the kernel From: Pawel Moll To: Andy Green Cc: Amit Daniel Kachhap , Zhang Rui , Viresh Kumar , Daniel Lezcano , Jean Delvare , Guenter Roeck , Steven Rostedt , Frederic Weisbecker , Ingo Molnar , Jesper Juhl , Thomas Renninger , Jean Pihet , "linaro-dev@lists.linaro.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "lm-sensors@lm-sensors.org" Date: Wed, 24 Oct 2012 17:05:11 +0100 In-Reply-To: <5086E6D6.8000208@linaro.org> References: <1351013449.9070.5.camel@hornet> <5086E6D6.8000208@linaro.org> X-Mailer: Evolution 3.6.0-0ubuntu3 Mime-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2012 16:05:12.0523 (UTC) FILETIME=[5938F9B0:01CDB201] X-MC-Unique: 112102417051500601 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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ł From mboxrd@z Thu Jan 1 00:00:00 1970 From: pawel.moll@arm.com (Pawel Moll) Date: Wed, 24 Oct 2012 17:05:11 +0100 Subject: [RFC] Energy/power monitoring within the kernel In-Reply-To: <5086E6D6.8000208@linaro.org> References: <1351013449.9070.5.camel@hornet> <5086E6D6.8000208@linaro.org> Message-ID: <1351094711.23327.47.camel@hornet> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pawel Moll Date: Wed, 24 Oct 2012 16:05:11 +0000 Subject: Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel Message-Id: <1351094711.23327.47.camel@hornet> List-Id: References: <1351013449.9070.5.camel@hornet> <5086E6D6.8000208@linaro.org> In-Reply-To: <5086E6D6.8000208@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andy Green Cc: Amit Daniel Kachhap , Zhang Rui , Viresh Kumar , Daniel Lezcano , Jean Delvare , Guenter Roeck , Steven Rostedt , Frederic Weisbecker , Ingo Molnar , Jesper Juhl , Thomas Renninger , Jean Pihet , "linaro-dev@lists.linaro.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "lm-sensors@lm-sensors.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