diff for duplicates of <1351094432.23327.42.camel@hornet> diff --git a/a/1.txt b/N1/1.txt index efe28aa..2eadfed 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,29 +1,37 @@ -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= +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? diff --git a/a/content_digest b/N1/content_digest index f0a1d34..2d28306 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,54 +1,47 @@ "ref\01351013449.9070.5.camel@hornet\0" "ref\01351014187.8467.24.camel@gandalf.local.home\0" - "From\0Pawel Moll <pawel.moll@arm.com>\0" - "Subject\0Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel\0" - "Date\0Wed, 24 Oct 2012 16:00:32 +0000\0" - "To\0Steven Rostedt <rostedt@goodmis.org>\0" - "Cc\0Amit 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>\0" + "From\0pawel.moll@arm.com (Pawel Moll)\0" + "Subject\0[RFC] Energy/power monitoring within the kernel\0" + "Date\0Wed, 24 Oct 2012 17:00:32 +0100\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" - "T24gVHVlLCAyMDEyLTEwLTIzIGF0IDE4OjQzICswMTAwLCBTdGV2ZW4gUm9zdGVkdCB3cm90ZToK\n" - "PiA+IDwuLi4+MjEyLjY3MzEyNjogaHdtb25fYXR0cl91cGRhdGU6IGh3bW9uNCB0ZW1wMV9pbnB1\n" - "dCAzNDM2MQo+ID4gCj4gPiBPbmUgaXNzdWUgd2l0aCB0aGlzIGlzIHRoYXQgc29tZSBleHRlcm5h\n" - "bCBrbm93bGVkZ2UgaXMgcmVxdWlyZWQgdG8KPiA+IHJlbGF0ZSBhIG51bWJlciB0byBhIHByb2Nl\n" - "c3NvciBjb3JlLiBPciBtYXliZSBpdCdzIG5vdCBhbiBpc3N1ZSBhdCBhbGwKPiA+IGJlY2F1c2Ug\n" - "aXQgc2hvdWxkIGJlIGxlZnQgZm9yIHRoZSB1c2VyKHNwYWNlKT8KPiAKPiBJZiB0aGUgZXh0ZXJu\n" - "YWwga25vd2xlZGdlIGNhbiBiZSBjaGFyYWN0ZXJpemVkIGluIGEgdXNlcnNwYWNlIHRvb2wgd2l0\n" - "aAo+IHRoZSBnaXZlbiBkYXRhIGhlcmUsIEkgc2VlIG5vIGlzc3VlcyB3aXRoIHRoaXMuCgpPaywg\n" - "ZmluZS4KCj4gPiAJVFBfZmFzdF9hc3NpZ24oCj4gPiAJCW1lbWNweShfX2VudHJ5LT5jcHVzLCBj\n" - "cHVzLCBzaXplb2Yoc3RydWN0IGNwdW1hc2spKTsKPiAKPiBDb3B5aW5nIHRoZSBlbnRpcmUgY3B1\n" - "bWFzayBzZWVtcyBsaWtlIG92ZXJraWxsLiBFc3BlY2lhbGx5IHdoZW4geW91IGhhdmUKPiA0MDk2\n" - "IENQVSBtYWNoaW5lcy4KClVoLCByaWdodC4gSSBkaWRuJ3QgY29uc2lkZXIgc3VjaCB1c2UgY2Fz\n" - "ZS4uLgoKPiBQZXJoYXBzIG1ha2luZyBhIGZpZWxkIHRoYXQgY2FuIGJlIGEgc3Vic2V0IG9mIGNw\n" - "dXMgbWF5IGJlIGJldHRlci4gVGhhdAo+IHdheSB3ZSBkb24ndCB3YXN0ZSB0aGUgcmluZyBidWZm\n" - "ZXIgd2l0aCBsb3RzIG9mIHplcm9zLiBJJ20gZ3Vlc3NpbmcgdGhhdAo+IGl0IHdpbGwgb25seSBi\n" - "ZSBhIGdyb3VwIG9mIGNwdXMsIGFuZCBub3QgYSBzY2F0dGVyZWQgbGlzdD8gT2YgY291cnNlLAo+\n" - "IEkndmUgc2VlbiBib3hlcyB3aGVyZSB0aGUgY3B1IG51bWJlcnMgd2VudCBmcm9tIGNvcmUgdG8g\n" - "Y29yZS4gVGhhdCBpcywKPiBjcHUgMCB3YXMgb24gY29yZSAxLCBjcHUgMSB3YXMgb24gY29yZSAy\n" - "LCBhbmQgdGhlbiBpdCB3b3VsZCByZXBlYXQuIAo+IGNwdSA4IHdhcyBvbiBjb3JlIDEsIGNwdSA5\n" - "IHdhcyBvbiBjb3JlIDIsIGV0Yy4KPiAKPiBCdXQgc3RpbGwsIHRoaXMgY291bGQgYmUgY29tcHJl\n" - "c3NlZCBzb21laG93LgoKU3VyZSB0aGluZy4gT3IgSSBjb3VsZCBzaW1wbHkgdXNlIGNwdW1hc2tf\n" - "c2NucHJpbnRmKCkgb24gdGhlIGFzc2lnbgpzdGFnZSBhbmQga2VlcCBhbiBhbHJlYWR5LWZvcm1h\n" - "dHRlZCBzdHJpbmcuIE9yLCBhcyB0aGUgY3B1bWFzayBwZXIKc2Vuc29yIHdvdWxkIGJlIGRlLWZh\n" - "Y3RvIGNvbnN0YW50LCBJIGNvdWxkIGFzc3VtZSBrZWVwIG9ubHkgYSBwb2ludGVyIHRvCml0LiBX\n" - "aWxsIGtlZXAgaXQgaW4gbWluZCBpZiB0aGlzIGV2ZW50IHdhcyBzdXBwb3NlZCB0byBoYXBwZW4u\n" - "CgpUaGFua3MhCgpQYXdlxYIKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f\n" - "X19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29y\n" - "cy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vu\n" - c29ycw= + "On Tue, 2012-10-23 at 18:43 +0100, Steven Rostedt wrote:\n" + "> > <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361\n" + "> > \n" + "> > One issue with this is that some external knowledge is required to\n" + "> > relate a number to a processor core. Or maybe it's not an issue at all\n" + "> > because it should be left for the user(space)?\n" + "> \n" + "> If the external knowledge can be characterized in a userspace tool with\n" + "> the given data here, I see no issues with this.\n" + "\n" + "Ok, fine.\n" + "\n" + "> > \tTP_fast_assign(\n" + "> > \t\tmemcpy(__entry->cpus, cpus, sizeof(struct cpumask));\n" + "> \n" + "> Copying the entire cpumask seems like overkill. Especially when you have\n" + "> 4096 CPU machines.\n" + "\n" + "Uh, right. I didn't consider such use case...\n" + "\n" + "> Perhaps making a field that can be a subset of cpus may be better. That\n" + "> way we don't waste the ring buffer with lots of zeros. I'm guessing that\n" + "> it will only be a group of cpus, and not a scattered list? Of course,\n" + "> I've seen boxes where the cpu numbers went from core to core. That is,\n" + "> cpu 0 was on core 1, cpu 1 was on core 2, and then it would repeat. \n" + "> cpu 8 was on core 1, cpu 9 was on core 2, etc.\n" + "> \n" + "> But still, this could be compressed somehow.\n" + "\n" + "Sure thing. Or I could simply use cpumask_scnprintf() on the assign\n" + "stage and keep an already-formatted string. Or, as the cpumask per\n" + "sensor would be de-facto constant, I could assume keep only a pointer to\n" + "it. Will keep it in mind if this event was supposed to happen.\n" + "\n" + "Thanks!\n" + "\n" + Pawe? -8ba78c4d4d14538d2d9da7d6368e56f3ffb4346419267d7b59e3bef61096e477 +40ff4a807dccbf6816c8c755176d3f53bb4810ed506f6e7e56be8d51dd3c5a50
diff --git a/a/1.txt b/N2/1.txt index efe28aa..826267c 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,29 +1,37 @@ -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= +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ł diff --git a/a/content_digest b/N2/content_digest index f0a1d34..22784bb 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,8 +1,8 @@ "ref\01351013449.9070.5.camel@hornet\0" "ref\01351014187.8467.24.camel@gandalf.local.home\0" "From\0Pawel Moll <pawel.moll@arm.com>\0" - "Subject\0Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel\0" - "Date\0Wed, 24 Oct 2012 16:00:32 +0000\0" + "Subject\0Re: [RFC] Energy/power monitoring within the kernel\0" + "Date\0Wed, 24 Oct 2012 17:00:32 +0100\0" "To\0Steven Rostedt <rostedt@goodmis.org>\0" "Cc\0Amit Daniel Kachhap <amit.kachhap@linaro.org>" Zhang Rui <rui.zhang@intel.com> @@ -21,34 +21,42 @@ " linaro-dev@lists.linaro.org <linaro-dev@lists.linaro.org>\0" "\00:1\0" "b\0" - "T24gVHVlLCAyMDEyLTEwLTIzIGF0IDE4OjQzICswMTAwLCBTdGV2ZW4gUm9zdGVkdCB3cm90ZToK\n" - "PiA+IDwuLi4+MjEyLjY3MzEyNjogaHdtb25fYXR0cl91cGRhdGU6IGh3bW9uNCB0ZW1wMV9pbnB1\n" - "dCAzNDM2MQo+ID4gCj4gPiBPbmUgaXNzdWUgd2l0aCB0aGlzIGlzIHRoYXQgc29tZSBleHRlcm5h\n" - "bCBrbm93bGVkZ2UgaXMgcmVxdWlyZWQgdG8KPiA+IHJlbGF0ZSBhIG51bWJlciB0byBhIHByb2Nl\n" - "c3NvciBjb3JlLiBPciBtYXliZSBpdCdzIG5vdCBhbiBpc3N1ZSBhdCBhbGwKPiA+IGJlY2F1c2Ug\n" - "aXQgc2hvdWxkIGJlIGxlZnQgZm9yIHRoZSB1c2VyKHNwYWNlKT8KPiAKPiBJZiB0aGUgZXh0ZXJu\n" - "YWwga25vd2xlZGdlIGNhbiBiZSBjaGFyYWN0ZXJpemVkIGluIGEgdXNlcnNwYWNlIHRvb2wgd2l0\n" - "aAo+IHRoZSBnaXZlbiBkYXRhIGhlcmUsIEkgc2VlIG5vIGlzc3VlcyB3aXRoIHRoaXMuCgpPaywg\n" - "ZmluZS4KCj4gPiAJVFBfZmFzdF9hc3NpZ24oCj4gPiAJCW1lbWNweShfX2VudHJ5LT5jcHVzLCBj\n" - "cHVzLCBzaXplb2Yoc3RydWN0IGNwdW1hc2spKTsKPiAKPiBDb3B5aW5nIHRoZSBlbnRpcmUgY3B1\n" - "bWFzayBzZWVtcyBsaWtlIG92ZXJraWxsLiBFc3BlY2lhbGx5IHdoZW4geW91IGhhdmUKPiA0MDk2\n" - "IENQVSBtYWNoaW5lcy4KClVoLCByaWdodC4gSSBkaWRuJ3QgY29uc2lkZXIgc3VjaCB1c2UgY2Fz\n" - "ZS4uLgoKPiBQZXJoYXBzIG1ha2luZyBhIGZpZWxkIHRoYXQgY2FuIGJlIGEgc3Vic2V0IG9mIGNw\n" - "dXMgbWF5IGJlIGJldHRlci4gVGhhdAo+IHdheSB3ZSBkb24ndCB3YXN0ZSB0aGUgcmluZyBidWZm\n" - "ZXIgd2l0aCBsb3RzIG9mIHplcm9zLiBJJ20gZ3Vlc3NpbmcgdGhhdAo+IGl0IHdpbGwgb25seSBi\n" - "ZSBhIGdyb3VwIG9mIGNwdXMsIGFuZCBub3QgYSBzY2F0dGVyZWQgbGlzdD8gT2YgY291cnNlLAo+\n" - "IEkndmUgc2VlbiBib3hlcyB3aGVyZSB0aGUgY3B1IG51bWJlcnMgd2VudCBmcm9tIGNvcmUgdG8g\n" - "Y29yZS4gVGhhdCBpcywKPiBjcHUgMCB3YXMgb24gY29yZSAxLCBjcHUgMSB3YXMgb24gY29yZSAy\n" - "LCBhbmQgdGhlbiBpdCB3b3VsZCByZXBlYXQuIAo+IGNwdSA4IHdhcyBvbiBjb3JlIDEsIGNwdSA5\n" - "IHdhcyBvbiBjb3JlIDIsIGV0Yy4KPiAKPiBCdXQgc3RpbGwsIHRoaXMgY291bGQgYmUgY29tcHJl\n" - "c3NlZCBzb21laG93LgoKU3VyZSB0aGluZy4gT3IgSSBjb3VsZCBzaW1wbHkgdXNlIGNwdW1hc2tf\n" - "c2NucHJpbnRmKCkgb24gdGhlIGFzc2lnbgpzdGFnZSBhbmQga2VlcCBhbiBhbHJlYWR5LWZvcm1h\n" - "dHRlZCBzdHJpbmcuIE9yLCBhcyB0aGUgY3B1bWFzayBwZXIKc2Vuc29yIHdvdWxkIGJlIGRlLWZh\n" - "Y3RvIGNvbnN0YW50LCBJIGNvdWxkIGFzc3VtZSBrZWVwIG9ubHkgYSBwb2ludGVyIHRvCml0LiBX\n" - "aWxsIGtlZXAgaXQgaW4gbWluZCBpZiB0aGlzIGV2ZW50IHdhcyBzdXBwb3NlZCB0byBoYXBwZW4u\n" - "CgpUaGFua3MhCgpQYXdlxYIKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f\n" - "X19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29y\n" - "cy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vu\n" - c29ycw= + "On Tue, 2012-10-23 at 18:43 +0100, Steven Rostedt wrote:\n" + "> > <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361\n" + "> > \n" + "> > One issue with this is that some external knowledge is required to\n" + "> > relate a number to a processor core. Or maybe it's not an issue at all\n" + "> > because it should be left for the user(space)?\n" + "> \n" + "> If the external knowledge can be characterized in a userspace tool with\n" + "> the given data here, I see no issues with this.\n" + "\n" + "Ok, fine.\n" + "\n" + "> > \tTP_fast_assign(\n" + "> > \t\tmemcpy(__entry->cpus, cpus, sizeof(struct cpumask));\n" + "> \n" + "> Copying the entire cpumask seems like overkill. Especially when you have\n" + "> 4096 CPU machines.\n" + "\n" + "Uh, right. I didn't consider such use case...\n" + "\n" + "> Perhaps making a field that can be a subset of cpus may be better. That\n" + "> way we don't waste the ring buffer with lots of zeros. I'm guessing that\n" + "> it will only be a group of cpus, and not a scattered list? Of course,\n" + "> I've seen boxes where the cpu numbers went from core to core. That is,\n" + "> cpu 0 was on core 1, cpu 1 was on core 2, and then it would repeat. \n" + "> cpu 8 was on core 1, cpu 9 was on core 2, etc.\n" + "> \n" + "> But still, this could be compressed somehow.\n" + "\n" + "Sure thing. Or I could simply use cpumask_scnprintf() on the assign\n" + "stage and keep an already-formatted string. Or, as the cpumask per\n" + "sensor would be de-facto constant, I could assume keep only a pointer to\n" + "it. Will keep it in mind if this event was supposed to happen.\n" + "\n" + "Thanks!\n" + "\n" + "Pawe\305\202" -8ba78c4d4d14538d2d9da7d6368e56f3ffb4346419267d7b59e3bef61096e477 +ce36195139404341fcd5f41ad4e1dfa9280284a337828b4d9a7322dd1df9e788
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.