From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pawel Moll Date: Wed, 24 Oct 2012 16:00:32 +0000 Subject: Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel Message-Id: <1351094432.23327.42.camel@hornet> List-Id: References: <1351013449.9070.5.camel@hornet> <1351014187.8467.24.camel@gandalf.local.home> In-Reply-To: <1351014187.8467.24.camel@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Steven Rostedt Cc: Amit Daniel Kachhap , Zhang Rui , Viresh Kumar , Daniel Lezcano , Jean Delvare , Guenter Roeck , Frederic Weisbecker , Ingo Molnar , Jesper Juhl , Thomas Renninger , Jean Pihet , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "lm-sensors@lm-sensors.org" , "linaro-dev@lists.linaro.org" T24gVHVlLCAyMDEyLTEwLTIzIGF0IDE4OjQzICswMTAwLCBTdGV2ZW4gUm9zdGVkdCB3cm90ZToK PiA+IDwuLi4+MjEyLjY3MzEyNjogaHdtb25fYXR0cl91cGRhdGU6IGh3bW9uNCB0ZW1wMV9pbnB1 dCAzNDM2MQo+ID4gCj4gPiBPbmUgaXNzdWUgd2l0aCB0aGlzIGlzIHRoYXQgc29tZSBleHRlcm5h bCBrbm93bGVkZ2UgaXMgcmVxdWlyZWQgdG8KPiA+IHJlbGF0ZSBhIG51bWJlciB0byBhIHByb2Nl c3NvciBjb3JlLiBPciBtYXliZSBpdCdzIG5vdCBhbiBpc3N1ZSBhdCBhbGwKPiA+IGJlY2F1c2Ug aXQgc2hvdWxkIGJlIGxlZnQgZm9yIHRoZSB1c2VyKHNwYWNlKT8KPiAKPiBJZiB0aGUgZXh0ZXJu YWwga25vd2xlZGdlIGNhbiBiZSBjaGFyYWN0ZXJpemVkIGluIGEgdXNlcnNwYWNlIHRvb2wgd2l0 aAo+IHRoZSBnaXZlbiBkYXRhIGhlcmUsIEkgc2VlIG5vIGlzc3VlcyB3aXRoIHRoaXMuCgpPaywg ZmluZS4KCj4gPiAJVFBfZmFzdF9hc3NpZ24oCj4gPiAJCW1lbWNweShfX2VudHJ5LT5jcHVzLCBj cHVzLCBzaXplb2Yoc3RydWN0IGNwdW1hc2spKTsKPiAKPiBDb3B5aW5nIHRoZSBlbnRpcmUgY3B1 bWFzayBzZWVtcyBsaWtlIG92ZXJraWxsLiBFc3BlY2lhbGx5IHdoZW4geW91IGhhdmUKPiA0MDk2 IENQVSBtYWNoaW5lcy4KClVoLCByaWdodC4gSSBkaWRuJ3QgY29uc2lkZXIgc3VjaCB1c2UgY2Fz ZS4uLgoKPiBQZXJoYXBzIG1ha2luZyBhIGZpZWxkIHRoYXQgY2FuIGJlIGEgc3Vic2V0IG9mIGNw dXMgbWF5IGJlIGJldHRlci4gVGhhdAo+IHdheSB3ZSBkb24ndCB3YXN0ZSB0aGUgcmluZyBidWZm ZXIgd2l0aCBsb3RzIG9mIHplcm9zLiBJJ20gZ3Vlc3NpbmcgdGhhdAo+IGl0IHdpbGwgb25seSBi ZSBhIGdyb3VwIG9mIGNwdXMsIGFuZCBub3QgYSBzY2F0dGVyZWQgbGlzdD8gT2YgY291cnNlLAo+ IEkndmUgc2VlbiBib3hlcyB3aGVyZSB0aGUgY3B1IG51bWJlcnMgd2VudCBmcm9tIGNvcmUgdG8g Y29yZS4gVGhhdCBpcywKPiBjcHUgMCB3YXMgb24gY29yZSAxLCBjcHUgMSB3YXMgb24gY29yZSAy LCBhbmQgdGhlbiBpdCB3b3VsZCByZXBlYXQuIAo+IGNwdSA4IHdhcyBvbiBjb3JlIDEsIGNwdSA5 IHdhcyBvbiBjb3JlIDIsIGV0Yy4KPiAKPiBCdXQgc3RpbGwsIHRoaXMgY291bGQgYmUgY29tcHJl c3NlZCBzb21laG93LgoKU3VyZSB0aGluZy4gT3IgSSBjb3VsZCBzaW1wbHkgdXNlIGNwdW1hc2tf c2NucHJpbnRmKCkgb24gdGhlIGFzc2lnbgpzdGFnZSBhbmQga2VlcCBhbiBhbHJlYWR5LWZvcm1h dHRlZCBzdHJpbmcuIE9yLCBhcyB0aGUgY3B1bWFzayBwZXIKc2Vuc29yIHdvdWxkIGJlIGRlLWZh Y3RvIGNvbnN0YW50LCBJIGNvdWxkIGFzc3VtZSBrZWVwIG9ubHkgYSBwb2ludGVyIHRvCml0LiBX aWxsIGtlZXAgaXQgaW4gbWluZCBpZiB0aGlzIGV2ZW50IHdhcyBzdXBwb3NlZCB0byBoYXBwZW4u CgpUaGFua3MhCgpQYXdlxYIKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29y cy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vu c29ycw= From mboxrd@z Thu Jan 1 00:00:00 1970 From: pawel.moll@arm.com (Pawel Moll) Date: Wed, 24 Oct 2012 17:00:32 +0100 Subject: [RFC] Energy/power monitoring within the kernel In-Reply-To: <1351014187.8467.24.camel@gandalf.local.home> References: <1351013449.9070.5.camel@hornet> <1351014187.8467.24.camel@gandalf.local.home> Message-ID: <1351094432.23327.42.camel@hornet> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, 2012-10-23 at 18:43 +0100, Steven Rostedt wrote: > > <...>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)? > > If the external knowledge can be characterized in a userspace tool with > the given data here, I see no issues with this. Ok, fine. > > TP_fast_assign( > > memcpy(__entry->cpus, cpus, sizeof(struct cpumask)); > > Copying the entire cpumask seems like overkill. Especially when you have > 4096 CPU machines. Uh, right. I didn't consider such use case... > Perhaps making a field that can be a subset of cpus may be better. That > way we don't waste the ring buffer with lots of zeros. I'm guessing that > it will only be a group of cpus, and not a scattered list? Of course, > I've seen boxes where the cpu numbers went from core to core. That is, > cpu 0 was on core 1, cpu 1 was on core 2, and then it would repeat. > cpu 8 was on core 1, cpu 9 was on core 2, etc. > > But still, this could be compressed somehow. Sure thing. Or I could simply use cpumask_scnprintf() on the assign stage and keep an already-formatted string. Or, as the cpumask per sensor would be de-facto constant, I could assume keep only a pointer to it. Will keep it in mind if this event was supposed to happen. Thanks! Pawe? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758689Ab2JXQAk (ORCPT ); Wed, 24 Oct 2012 12:00:40 -0400 Received: from service87.mimecast.com ([91.220.42.44]:33126 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757859Ab2JXQAj convert rfc822-to-8bit (ORCPT ); Wed, 24 Oct 2012 12:00:39 -0400 Message-ID: <1351094432.23327.42.camel@hornet> Subject: Re: [RFC] Energy/power monitoring within the kernel From: Pawel Moll To: Steven Rostedt Cc: Amit Daniel Kachhap , Zhang Rui , Viresh Kumar , Daniel Lezcano , Jean Delvare , Guenter Roeck , Frederic Weisbecker , Ingo Molnar , Jesper Juhl , Thomas Renninger , Jean Pihet , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "lm-sensors@lm-sensors.org" , "linaro-dev@lists.linaro.org" Date: Wed, 24 Oct 2012 17:00:32 +0100 In-Reply-To: <1351014187.8467.24.camel@gandalf.local.home> References: <1351013449.9070.5.camel@hornet> <1351014187.8467.24.camel@gandalf.local.home> X-Mailer: Evolution 3.6.0-0ubuntu3 Mime-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2012 16:00:32.0822 (UTC) FILETIME=[B281FD60:01CDB200] X-MC-Unique: 112102417003600801 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 18:43 +0100, Steven Rostedt wrote: > > <...>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)? > > If the external knowledge can be characterized in a userspace tool with > the given data here, I see no issues with this. Ok, fine. > > TP_fast_assign( > > memcpy(__entry->cpus, cpus, sizeof(struct cpumask)); > > Copying the entire cpumask seems like overkill. Especially when you have > 4096 CPU machines. Uh, right. I didn't consider such use case... > Perhaps making a field that can be a subset of cpus may be better. That > way we don't waste the ring buffer with lots of zeros. I'm guessing that > it will only be a group of cpus, and not a scattered list? Of course, > I've seen boxes where the cpu numbers went from core to core. That is, > cpu 0 was on core 1, cpu 1 was on core 2, and then it would repeat. > cpu 8 was on core 1, cpu 9 was on core 2, etc. > > But still, this could be compressed somehow. Sure thing. Or I could simply use cpumask_scnprintf() on the assign stage and keep an already-formatted string. Or, as the cpumask per sensor would be de-facto constant, I could assume keep only a pointer to it. Will keep it in mind if this event was supposed to happen. Thanks! Paweł