From: Pawel Moll <pawel.moll@arm.com>
To: Steven Rostedt <rostedt@goodmis.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>,
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>,
"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>,
"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>
Subject: Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel
Date: Wed, 24 Oct 2012 16:00:32 +0000 [thread overview]
Message-ID: <1351094432.23327.42.camel@hornet> (raw)
In-Reply-To: <1351014187.8467.24.camel@gandalf.local.home>
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=
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:00:32 +0100 [thread overview]
Message-ID: <1351094432.23327.42.camel@hornet> (raw)
In-Reply-To: <1351014187.8467.24.camel@gandalf.local.home>
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?
WARNING: multiple messages have this Message-ID (diff)
From: Pawel Moll <pawel.moll@arm.com>
To: Steven Rostedt <rostedt@goodmis.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>,
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>,
"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>,
"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>
Subject: Re: [RFC] Energy/power monitoring within the kernel
Date: Wed, 24 Oct 2012 17:00:32 +0100 [thread overview]
Message-ID: <1351094432.23327.42.camel@hornet> (raw)
In-Reply-To: <1351014187.8467.24.camel@gandalf.local.home>
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ł
next prev parent reply other threads:[~2012-10-24 16:00 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 ` Pawel Moll [this message]
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 ` [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=1351094432.23327.42.camel@hornet \
--to=pawel.moll@arm.com \
--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=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.