Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1201865 > unrolled thread

Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support

Started byPeter Zijlstra <peterz@infradead.org>
First post2015-08-06 17:50 +0200
Last post2015-08-06 23:40 +0200
Articles 12 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support Peter Zijlstra <peterz@infradead.org> - 2015-08-06 17:50 +0200
    Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support Stephane Eranian <eranian@google.com> - 2015-08-06 20:20 +0200
      RE: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support "Liang, Kan" <kan.liang@intel.com> - 2015-08-06 21:00 +0200
        Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support Stephane Eranian <eranian@google.com> - 2015-08-06 21:30 +0200
          RE: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support "Liang, Kan" <kan.liang@intel.com> - 2015-08-06 21:30 +0200
            Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support Stephane Eranian <eranian@google.com> - 2015-08-06 22:20 +0200
              RE: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support "Liang, Kan" <kan.liang@intel.com> - 2015-08-06 22:30 +0200
                Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support Stephane Eranian <eranian@google.com> - 2015-08-06 22:40 +0200
                  RE: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support "Liang, Kan" <kan.liang@intel.com> - 2015-08-06 23:50 +0200
                    Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support Stephane Eranian <eranian@google.com> - 2015-08-07 01:20 +0200
                      RE: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support "Liang, Kan" <kan.liang@intel.com> - 2015-08-07 01:50 +0200
      Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support Peter Zijlstra <peterz@infradead.org> - 2015-08-06 23:40 +0200

#1201865 — Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support

FromPeter Zijlstra <peterz@infradead.org>
Date2015-08-06 17:50 +0200
SubjectRe: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support
Message-ID<pUvAC-4Wc-5@gated-at.bofh.it>
On Mon, Jul 27, 2015 at 04:46:16AM -0400, kan.liang@intel.com wrote:

As a general comment; this thing is unreadable. Far too much macro foo
to instantiate the different PMUs.

> +struct perf_power_cstate_event_msr {
> +	int	id;
> +	u64	msr;
> +};
> +
> +enum perf_power_cstate_id {
> +	/*
> +	 * power_cstate events, generalized by the kernel:
> +	 */
> +	PERF_POWER_CORE_C1_RES = 0,
> +	PERF_POWER_CORE_C3_RES,
> +	PERF_POWER_CORE_C6_RES,
> +	PERF_POWER_CORE_C7_RES,

These are two different PMUs, why are they in the same enum space?

> +	PERF_POWER_PKG_C2_RES,
> +	PERF_POWER_PKG_C3_RES,
> +	PERF_POWER_PKG_C6_RES,
> +	PERF_POWER_PKG_C7_RES,
> +	PERF_POWER_PKG_C8_RES,
> +	PERF_POWER_PKG_C9_RES,
> +	PERF_POWER_PKG_C10_RES,
> +
> +	PERF_POWER_CSTATE_EVENT_MAX,       /* non-ABI */
> +};
> +
> +struct power_cstate_pmu {
> +	struct intel_power_cstate_type	*power_cstate_type;
> +	struct pmu			*pmu;
> +};
> +
> +
> +static struct intel_power_cstate_type *empty_power_cstate[] = { NULL, };
> +struct intel_power_cstate_type **power_cstate = empty_power_cstate;
> +
> +static struct perf_power_cstate_event_msr power_cstate_events[] = {
> +	{ PERF_POWER_CORE_C1_RES, MSR_CORE_C1_RES },
> +	{ PERF_POWER_CORE_C3_RES, MSR_CORE_C3_RESIDENCY },
> +	{ PERF_POWER_CORE_C6_RES, MSR_CORE_C6_RESIDENCY },
> +	{ PERF_POWER_CORE_C7_RES, MSR_CORE_C7_RESIDENCY },
> +	{ PERF_POWER_PKG_C2_RES, MSR_PKG_C2_RESIDENCY },
> +	{ PERF_POWER_PKG_C3_RES, MSR_PKG_C3_RESIDENCY },
> +	{ PERF_POWER_PKG_C6_RES, MSR_PKG_C6_RESIDENCY },
> +	{ PERF_POWER_PKG_C7_RES, MSR_PKG_C7_RESIDENCY },
> +	{ PERF_POWER_PKG_C8_RES, MSR_PKG_C8_RESIDENCY },
> +	{ PERF_POWER_PKG_C9_RES, MSR_PKG_C9_RESIDENCY },
> +	{ PERF_POWER_PKG_C10_RES, MSR_PKG_C10_RESIDENCY },
> +};

What's the point of the first entry? You already know which index it is,
no point in storing that again.

> +
> +EVENT_ATTR_STR(c1-residency, power_core_c1_res, "event=0x00");
> +EVENT_ATTR_STR(c3-residency, power_core_c3_res, "event=0x01");
> +EVENT_ATTR_STR(c6-residency, power_core_c6_res, "event=0x02");
> +EVENT_ATTR_STR(c7-residency, power_core_c7_res, "event=0x03");

> +EVENT_ATTR_STR(c2-residency, power_pkg_c2_res, "event=0x04");

I would very much expect this thing to start counting at 0 again.

> +EVENT_ATTR_STR(c3-residency, power_pkg_c3_res, "event=0x05");
> +EVENT_ATTR_STR(c6-residency, power_pkg_c6_res, "event=0x06");
> +EVENT_ATTR_STR(c7-residency, power_pkg_c7_res, "event=0x07");
> +EVENT_ATTR_STR(c8-residency, power_pkg_c8_res, "event=0x08");
> +EVENT_ATTR_STR(c9-residency, power_pkg_c9_res, "event=0x09");
> +EVENT_ATTR_STR(c10-residency, power_pkg_c10_res, "event=0x0a");
> +
> +static cpumask_t power_cstate_core_cpu_mask;

That one typically does not need a cpumask.

> +static cpumask_t power_cstate_pkg_cpu_mask;

> +static int power_cstate_pmu_event_init(struct perf_event *event)
> +{
> +	u64 cfg = event->attr.config;
> +	int ret = 0;
> +
> +	if (event->attr.type != event->pmu->type)
> +		return -ENOENT;
> +
> +	/*
> +	 * check event is known (determines counter)
> +	 */
> +	if (cfg >= PERF_POWER_CSTATE_EVENT_MAX)
> +		return -EINVAL;
> +
> +	/* unsupported modes and filters */
> +	if (event->attr.exclude_user   ||
> +	    event->attr.exclude_kernel ||
> +	    event->attr.exclude_hv     ||
> +	    event->attr.exclude_idle   ||
> +	    event->attr.exclude_host   ||
> +	    event->attr.exclude_guest  ||
> +	    event->attr.sample_period) /* no sampling */
> +		return -EINVAL;

Same as with the MSR thing, but worse. What happens if we hand a config
value for the 'wrong' PMU type?

What happens if we hand a pkg c10 config to one that doesn't have c10?

> +	/* must be done before validate_group */
> +	event->hw.event_base = power_cstate_events[cfg].msr;
> +	event->hw.config = cfg;
> +	event->hw.idx = -1;
> +
> +	return ret;
> +}
> +
> +static inline u64 power_cstate_pmu_read_counter(struct perf_event *event)
> +{
> +	u64 val;
> +
> +	rdmsrl_safe(event->hw.event_base, &val);

No, at this point you had better know if that MSR exists or not. If it
does not the event should not exist.

> +	return val;
> +}

 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1201959

FromStephane Eranian <eranian@google.com>
Date2015-08-06 20:20 +0200
Message-ID<pUxVM-8tG-7@gated-at.bofh.it>
In reply to#1201865
On Thu, Aug 6, 2015 at 8:44 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, Jul 27, 2015 at 04:46:16AM -0400, kan.liang@intel.com wrote:
>
> As a general comment; this thing is unreadable. Far too much macro foo
> to instantiate the different PMUs.
>
>> +struct perf_power_cstate_event_msr {
>> +     int     id;
>> +     u64     msr;
>> +};
>> +
>> +enum perf_power_cstate_id {
>> +     /*
>> +      * power_cstate events, generalized by the kernel:
>> +      */
>> +     PERF_POWER_CORE_C1_RES = 0,
>> +     PERF_POWER_CORE_C3_RES,
>> +     PERF_POWER_CORE_C6_RES,
>> +     PERF_POWER_CORE_C7_RES,
>
> These are two different PMUs, why are they in the same enum space?
>
>> +     PERF_POWER_PKG_C2_RES,
>> +     PERF_POWER_PKG_C3_RES,
>> +     PERF_POWER_PKG_C6_RES,
>> +     PERF_POWER_PKG_C7_RES,
>> +     PERF_POWER_PKG_C8_RES,
>> +     PERF_POWER_PKG_C9_RES,
>> +     PERF_POWER_PKG_C10_RES,
>> +
>> +     PERF_POWER_CSTATE_EVENT_MAX,       /* non-ABI */
>> +};
>> +
>> +struct power_cstate_pmu {
>> +     struct intel_power_cstate_type  *power_cstate_type;
>> +     struct pmu                      *pmu;
>> +};
>> +
>> +
>> +static struct intel_power_cstate_type *empty_power_cstate[] = { NULL, };
>> +struct intel_power_cstate_type **power_cstate = empty_power_cstate;
>> +
>> +static struct perf_power_cstate_event_msr power_cstate_events[] = {
>> +     { PERF_POWER_CORE_C1_RES, MSR_CORE_C1_RES },
>> +     { PERF_POWER_CORE_C3_RES, MSR_CORE_C3_RESIDENCY },
>> +     { PERF_POWER_CORE_C6_RES, MSR_CORE_C6_RESIDENCY },
>> +     { PERF_POWER_CORE_C7_RES, MSR_CORE_C7_RESIDENCY },
>> +     { PERF_POWER_PKG_C2_RES, MSR_PKG_C2_RESIDENCY },
>> +     { PERF_POWER_PKG_C3_RES, MSR_PKG_C3_RESIDENCY },
>> +     { PERF_POWER_PKG_C6_RES, MSR_PKG_C6_RESIDENCY },
>> +     { PERF_POWER_PKG_C7_RES, MSR_PKG_C7_RESIDENCY },
>> +     { PERF_POWER_PKG_C8_RES, MSR_PKG_C8_RESIDENCY },
>> +     { PERF_POWER_PKG_C9_RES, MSR_PKG_C9_RESIDENCY },
>> +     { PERF_POWER_PKG_C10_RES, MSR_PKG_C10_RESIDENCY },
>> +};
>
> What's the point of the first entry? You already know which index it is,
> no point in storing that again.
>
>> +
>> +EVENT_ATTR_STR(c1-residency, power_core_c1_res, "event=0x00");

I would not use an event code of 0. Start at 0x1

>> +EVENT_ATTR_STR(c3-residency, power_core_c3_res, "event=0x01");
>> +EVENT_ATTR_STR(c6-residency, power_core_c6_res, "event=0x02");
>> +EVENT_ATTR_STR(c7-residency, power_core_c7_res, "event=0x03");
>
>> +EVENT_ATTR_STR(c2-residency, power_pkg_c2_res, "event=0x04");
>
> I would very much expect this thing to start counting at 0 again.
>
>> +EVENT_ATTR_STR(c3-residency, power_pkg_c3_res, "event=0x05");
>> +EVENT_ATTR_STR(c6-residency, power_pkg_c6_res, "event=0x06");
>> +EVENT_ATTR_STR(c7-residency, power_pkg_c7_res, "event=0x07");
>> +EVENT_ATTR_STR(c8-residency, power_pkg_c8_res, "event=0x08");
>> +EVENT_ATTR_STR(c9-residency, power_pkg_c9_res, "event=0x09");
>> +EVENT_ATTR_STR(c10-residency, power_pkg_c10_res, "event=0x0a");
>> +
>> +static cpumask_t power_cstate_core_cpu_mask;
>
> That one typically does not need a cpumask.
>
You need to pick one CPU out of the multi-core. But it is for client parts thus
there is only one socket. At least this is my understanding.

>> +static cpumask_t power_cstate_pkg_cpu_mask;
>
>> +static int power_cstate_pmu_event_init(struct perf_event *event)
>> +{
>> +     u64 cfg = event->attr.config;
>> +     int ret = 0;
>> +
>> +     if (event->attr.type != event->pmu->type)
>> +             return -ENOENT;
>> +
>> +     /*
>> +      * check event is known (determines counter)
>> +      */
>> +     if (cfg >= PERF_POWER_CSTATE_EVENT_MAX)
>> +             return -EINVAL;
>> +
>> +     /* unsupported modes and filters */
>> +     if (event->attr.exclude_user   ||
>> +         event->attr.exclude_kernel ||
>> +         event->attr.exclude_hv     ||
>> +         event->attr.exclude_idle   ||
>> +         event->attr.exclude_host   ||
>> +         event->attr.exclude_guest  ||
>> +         event->attr.sample_period) /* no sampling */
>> +             return -EINVAL;
>
> Same as with the MSR thing, but worse. What happens if we hand a config
> value for the 'wrong' PMU type?
>
I think that's taken care of by the first test in the function.

> What happens if we hand a pkg c10 config to one that doesn't have c10?
>
>> +     /* must be done before validate_group */
>> +     event->hw.event_base = power_cstate_events[cfg].msr;
>> +     event->hw.config = cfg;
>> +     event->hw.idx = -1;
>> +
>> +     return ret;
>> +}
>> +
>> +static inline u64 power_cstate_pmu_read_counter(struct perf_event *event)
>> +{
>> +     u64 val;
>> +
>> +     rdmsrl_safe(event->hw.event_base, &val);
>
> No, at this point you had better know if that MSR exists or not. If it
> does not the event should not exist.
>
>> +     return val;
>> +}
>
>
I understand that these metrics are useful and needed however if I
look at the broader
picture I see many PMUs doing similar things or appearing different
when they are actually
very close. It would be nice to have a more unified approach. You have
RAPL (client, server)
which appears as the power PMU. You have the PCU uncore on servers
which also provides
C-state residency info. Yet, all these appear differently and expose
events with different names.
I think we could benefit from a more unifie approach here such that
you would be able to do

$    perf stat -a -e power/c6-residency/, power/energy-pkg/

on client and server without having to change the pmu name of the event names.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1201979

From"Liang, Kan" <kan.liang@intel.com>
Date2015-08-06 21:00 +0200
Message-ID<pUyyu-L1-9@gated-at.bofh.it>
In reply to#1201959
DQoNCj4gPj4gK3N0YXRpYyBjcHVtYXNrX3QgcG93ZXJfY3N0YXRlX2NvcmVfY3B1X21hc2s7DQo+
ID4NCj4gPiBUaGF0IG9uZSB0eXBpY2FsbHkgZG9lcyBub3QgbmVlZCBhIGNwdW1hc2suDQo+ID4N
Cj4gWW91IG5lZWQgdG8gcGljayBvbmUgQ1BVIG91dCBvZiB0aGUgbXVsdGktY29yZS4gQnV0IGl0
IGlzIGZvciBjbGllbnQgcGFydHMNCj4gdGh1cyB0aGVyZSBpcyBvbmx5IG9uZSBzb2NrZXQuIEF0
IGxlYXN0IHRoaXMgaXMgbXkgdW5kZXJzdGFuZGluZy4NCj4gDQoNCkNPUkVfQypfUkVTSURFTkNZ
IGFyZSBhdmFpbGFibGUgZm9yIHBoeXNpY2FsIHByb2Nlc3NvciBjb3JlLg0KU28gbG9naWNhbCBw
cm9jZXNzb3IgaW4gc2FtZSBwaHlzaWNhbCBwcm9jZXNzb3IgY29yZSBzaGFyZSB0aGUgc2FtZQ0K
Y291bnRlci4gDQpJIHRoaW5rIHdlIG5lZWQgdGhlIGNwdW1hc2sgdG8gaWRlbnRpZnkgdGhlIGRl
ZmF1bHQgbG9naWNhbCBwcm9jZXNzb3Igd2hpY2gNCmRvIGNvdW50aW5nLg0KDQo+ID4NCj4gSSB1
bmRlcnN0YW5kIHRoYXQgdGhlc2UgbWV0cmljcyBhcmUgdXNlZnVsIGFuZCBuZWVkZWQgaG93ZXZl
ciBpZiBJIGxvb2sgYXQNCj4gdGhlIGJyb2FkZXIgcGljdHVyZSBJIHNlZSBtYW55IFBNVXMgZG9p
bmcgc2ltaWxhciB0aGluZ3Mgb3IgYXBwZWFyaW5nDQo+IGRpZmZlcmVudCB3aGVuIHRoZXkgYXJl
IGFjdHVhbGx5IHZlcnkgY2xvc2UuIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBhDQo+IG1vcmUg
dW5pZmllZCBhcHByb2FjaC4gWW91IGhhdmUgUkFQTCAoY2xpZW50LCBzZXJ2ZXIpIHdoaWNoIGFw
cGVhcnMgYXMNCj4gdGhlIHBvd2VyIFBNVS4gWW91IGhhdmUgdGhlIFBDVSB1bmNvcmUgb24gc2Vy
dmVycyB3aGljaCBhbHNvIHByb3ZpZGVzDQo+IEMtc3RhdGUgcmVzaWRlbmN5IGluZm8uIFlldCwg
YWxsIHRoZXNlIGFwcGVhciBkaWZmZXJlbnRseSBhbmQgZXhwb3NlIGV2ZW50cw0KPiB3aXRoIGRp
ZmZlcmVudCBuYW1lcy4NCj4gSSB0aGluayB3ZSBjb3VsZCBiZW5lZml0IGZyb20gYSBtb3JlIHVu
aWZpZSBhcHByb2FjaCBoZXJlIHN1Y2ggdGhhdCB5b3UNCj4gd291bGQgYmUgYWJsZSB0byBkbw0K
PiANCj4gJCAgICBwZXJmIHN0YXQgLWEgLWUgcG93ZXIvYzYtcmVzaWRlbmN5LywgcG93ZXIvZW5l
cmd5LXBrZy8NCj4gDQo+IG9uIGNsaWVudCBhbmQgc2VydmVyIHdpdGhvdXQgaGF2aW5nIHRvIGNo
YW5nZSB0aGUgcG11IG5hbWUgb2YgdGhlIGV2ZW50DQo+IG5hbWVzLg0KDQpZZXMsIEkgYWdyZWUu
IEknbGwgdGhpbmsgYWJvdXQgaXQuDQoNClRoYW5rcywNCkthbg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1201987

FromStephane Eranian <eranian@google.com>
Date2015-08-06 21:30 +0200
Message-ID<pUz1w-1yi-13@gated-at.bofh.it>
In reply to#1201979
On Thu, Aug 6, 2015 at 11:52 AM, Liang, Kan <kan.liang@intel.com> wrote:
>
>
>> >> +static cpumask_t power_cstate_core_cpu_mask;
>> >
>> > That one typically does not need a cpumask.
>> >
>> You need to pick one CPU out of the multi-core. But it is for client parts
>> thus there is only one socket. At least this is my understanding.
>>
>
> CORE_C*_RESIDENCY are available for physical processor core.
> So logical processor in same physical processor core share the same
> counter.
> I think we need the cpumask to identify the default logical processor which
> do counting.
>
Did you restrict these events to system-wide mode only?

>> >
>> I understand that these metrics are useful and needed however if I look at
>> the broader picture I see many PMUs doing similar things or appearing
>> different when they are actually very close. It would be nice to have a
>> more unified approach. You have RAPL (client, server) which appears as
>> the power PMU. You have the PCU uncore on servers which also provides
>> C-state residency info. Yet, all these appear differently and expose events
>> with different names.
>> I think we could benefit from a more unifie approach here such that you
>> would be able to do
>>
>> $    perf stat -a -e power/c6-residency/, power/energy-pkg/
>>
>> on client and server without having to change the pmu name of the event
>> names.
>
> Yes, I agree. I'll think about it.
>
> Thanks,
> Kan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1201988

From"Liang, Kan" <kan.liang@intel.com>
Date2015-08-06 21:30 +0200
Message-ID<pUz1w-1yi-17@gated-at.bofh.it>
In reply to#1201987
DQo+IA0KPiBPbiBUaHUsIEF1ZyA2LCAyMDE1IGF0IDExOjUyIEFNLCBMaWFuZywgS2FuIDxrYW4u
bGlhbmdAaW50ZWwuY29tPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4+ID4+ICtzdGF0aWMgY3B1bWFz
a190IHBvd2VyX2NzdGF0ZV9jb3JlX2NwdV9tYXNrOw0KPiA+PiA+DQo+ID4+ID4gVGhhdCBvbmUg
dHlwaWNhbGx5IGRvZXMgbm90IG5lZWQgYSBjcHVtYXNrLg0KPiA+PiA+DQo+ID4+IFlvdSBuZWVk
IHRvIHBpY2sgb25lIENQVSBvdXQgb2YgdGhlIG11bHRpLWNvcmUuIEJ1dCBpdCBpcyBmb3IgY2xp
ZW50DQo+ID4+IHBhcnRzIHRodXMgdGhlcmUgaXMgb25seSBvbmUgc29ja2V0LiBBdCBsZWFzdCB0
aGlzIGlzIG15IHVuZGVyc3RhbmRpbmcuDQo+ID4+DQo+ID4NCj4gPiBDT1JFX0MqX1JFU0lERU5D
WSBhcmUgYXZhaWxhYmxlIGZvciBwaHlzaWNhbCBwcm9jZXNzb3IgY29yZS4NCj4gPiBTbyBsb2dp
Y2FsIHByb2Nlc3NvciBpbiBzYW1lIHBoeXNpY2FsIHByb2Nlc3NvciBjb3JlIHNoYXJlIHRoZSBz
YW1lDQo+ID4gY291bnRlci4NCj4gPiBJIHRoaW5rIHdlIG5lZWQgdGhlIGNwdW1hc2sgdG8gaWRl
bnRpZnkgdGhlIGRlZmF1bHQgbG9naWNhbCBwcm9jZXNzb3INCj4gPiB3aGljaCBkbyBjb3VudGlu
Zy4NCj4gPg0KPiBEaWQgeW91IHJlc3RyaWN0IHRoZXNlIGV2ZW50cyB0byBzeXN0ZW0td2lkZSBt
b2RlIG9ubHk/DQo+DQogDQpZZXMNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1201999

FromStephane Eranian <eranian@google.com>
Date2015-08-06 22:20 +0200
Message-ID<pUzNU-2I6-19@gated-at.bofh.it>
In reply to#1201988
On Thu, Aug 6, 2015 at 12:25 PM, Liang, Kan <kan.liang@intel.com> wrote:
>
>>
>> On Thu, Aug 6, 2015 at 11:52 AM, Liang, Kan <kan.liang@intel.com> wrote:
>> >
>> >
>> >> >> +static cpumask_t power_cstate_core_cpu_mask;
>> >> >
>> >> > That one typically does not need a cpumask.
>> >> >
>> >> You need to pick one CPU out of the multi-core. But it is for client
>> >> parts thus there is only one socket. At least this is my understanding.
>> >>
>> >
>> > CORE_C*_RESIDENCY are available for physical processor core.
>> > So logical processor in same physical processor core share the same
>> > counter.
>> > I think we need the cpumask to identify the default logical processor
>> > which do counting.
>> >
>> Did you restrict these events to system-wide mode only?
>>
Ok, so that means that your cpumask includes one HT per physical core. But then,
the result is not the simple aggregation of all the N/2 CPUs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1202000

From"Liang, Kan" <kan.liang@intel.com>
Date2015-08-06 22:30 +0200
Message-ID<pUzXA-2T7-5@gated-at.bofh.it>
In reply to#1201999
DQo+ID4+ID4+ID4+ICtzdGF0aWMgY3B1bWFza190IHBvd2VyX2NzdGF0ZV9jb3JlX2NwdV9tYXNr
Ow0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gVGhhdCBvbmUgdHlwaWNhbGx5IGRvZXMgbm90IG5lZWQg
YSBjcHVtYXNrLg0KPiA+PiA+PiA+DQo+ID4+ID4+IFlvdSBuZWVkIHRvIHBpY2sgb25lIENQVSBv
dXQgb2YgdGhlIG11bHRpLWNvcmUuIEJ1dCBpdCBpcyBmb3INCj4gPj4gPj4gY2xpZW50IHBhcnRz
IHRodXMgdGhlcmUgaXMgb25seSBvbmUgc29ja2V0LiBBdCBsZWFzdCB0aGlzIGlzIG15DQo+IHVu
ZGVyc3RhbmRpbmcuDQo+ID4+ID4+DQo+ID4+ID4NCj4gPj4gPiBDT1JFX0MqX1JFU0lERU5DWSBh
cmUgYXZhaWxhYmxlIGZvciBwaHlzaWNhbCBwcm9jZXNzb3IgY29yZS4NCj4gPj4gPiBTbyBsb2dp
Y2FsIHByb2Nlc3NvciBpbiBzYW1lIHBoeXNpY2FsIHByb2Nlc3NvciBjb3JlIHNoYXJlIHRoZSBz
YW1lDQo+ID4+ID4gY291bnRlci4NCj4gPj4gPiBJIHRoaW5rIHdlIG5lZWQgdGhlIGNwdW1hc2sg
dG8gaWRlbnRpZnkgdGhlIGRlZmF1bHQgbG9naWNhbA0KPiA+PiA+IHByb2Nlc3NvciB3aGljaCBk
byBjb3VudGluZy4NCj4gPj4gPg0KPiA+PiBEaWQgeW91IHJlc3RyaWN0IHRoZXNlIGV2ZW50cyB0
byBzeXN0ZW0td2lkZSBtb2RlIG9ubHk/DQo+ID4+DQo+IE9rLCBzbyB0aGF0IG1lYW5zIHRoYXQg
eW91ciBjcHVtYXNrIGluY2x1ZGVzIG9uZSBIVCBwZXIgcGh5c2ljYWwgY29yZS4NCj4gQnV0IHRo
ZW4sIHRoZSByZXN1bHQgaXMgbm90IHRoZSBzaW1wbGUgYWdncmVnYXRpb24gb2YgYWxsIHRoZSBO
LzIgQ1BVcy4NCg0KVGhlIGNvdW50ZXIgY291bnRzIHBlciBwaHlzaWNhbCBjb3JlLiBUaGUgcmVz
dWx0IGlzIHRoZSBhZ2dyZWdhdGlvbiBvZg0KYWxsIEhUIGNwdXMgaW4gc2FtZSBwaHlzaWNhbCBj
b3JlLg0KSXQncyBzaW1pbGFyIGFzIHBlciBzb2NrZXQgY291bnRlci4gQnV0IHRoZSBzY29wZSBp
cyBwaHlzaWNhbCBjb3JlIG5vdy4NCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1202011

FromStephane Eranian <eranian@google.com>
Date2015-08-06 22:40 +0200
Message-ID<pUA7g-34H-17@gated-at.bofh.it>
In reply to#1202000
On Thu, Aug 6, 2015 at 1:25 PM, Liang, Kan <kan.liang@intel.com> wrote:
>
>> >> >> >> +static cpumask_t power_cstate_core_cpu_mask;
>> >> >> >
>> >> >> > That one typically does not need a cpumask.
>> >> >> >
>> >> >> You need to pick one CPU out of the multi-core. But it is for
>> >> >> client parts thus there is only one socket. At least this is my
>> understanding.
>> >> >>
>> >> >
>> >> > CORE_C*_RESIDENCY are available for physical processor core.
>> >> > So logical processor in same physical processor core share the same
>> >> > counter.
>> >> > I think we need the cpumask to identify the default logical
>> >> > processor which do counting.
>> >> >
>> >> Did you restrict these events to system-wide mode only?
>> >>
>> Ok, so that means that your cpumask includes one HT per physical core.
>> But then, the result is not the simple aggregation of all the N/2 CPUs.
>
> The counter counts per physical core. The result is the aggregation of
> all HT cpus in same physical core.

But then don't you need to divide by 2 to get a meaningful result?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1202097

From"Liang, Kan" <kan.liang@intel.com>
Date2015-08-06 23:50 +0200
Message-ID<pUBd0-4BZ-19@gated-at.bofh.it>
In reply to#1202011
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhhbmUgRXJhbmlh
biBbbWFpbHRvOmVyYW5pYW5AZ29vZ2xlLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAw
NiwgMjAxNSA0OjM4IFBNDQo+IFRvOiBMaWFuZywgS2FuDQo+IENjOiBQZXRlciBaaWpsc3RyYTsg
bWluZ29AcmVkaGF0LmNvbTsgQXJuYWxkbyBDYXJ2YWxobyBkZSBNZWxvOw0KPiBha0BsaW51eC5p
bnRlbC5jb207IExLTUwNCj4gU3ViamVjdDogUmU6IFtQQVRDSCBWMiAxLzFdIHBlcmYveDg2OiBB
ZGQgSW50ZWwgcG93ZXIgY3N0YXRlIFBNVXMNCj4gc3VwcG9ydA0KPiANCj4gT24gVGh1LCBBdWcg
NiwgMjAxNSBhdCAxOjI1IFBNLCBMaWFuZywgS2FuIDxrYW4ubGlhbmdAaW50ZWwuY29tPiB3cm90
ZToNCj4gPg0KPiA+PiA+PiA+PiA+PiArc3RhdGljIGNwdW1hc2tfdCBwb3dlcl9jc3RhdGVfY29y
ZV9jcHVfbWFzazsNCj4gPj4gPj4gPj4gPg0KPiA+PiA+PiA+PiA+IFRoYXQgb25lIHR5cGljYWxs
eSBkb2VzIG5vdCBuZWVkIGEgY3B1bWFzay4NCj4gPj4gPj4gPj4gPg0KPiA+PiA+PiA+PiBZb3Ug
bmVlZCB0byBwaWNrIG9uZSBDUFUgb3V0IG9mIHRoZSBtdWx0aS1jb3JlLiBCdXQgaXQgaXMgZm9y
DQo+ID4+ID4+ID4+IGNsaWVudCBwYXJ0cyB0aHVzIHRoZXJlIGlzIG9ubHkgb25lIHNvY2tldC4g
QXQgbGVhc3QgdGhpcyBpcyBteQ0KPiA+PiB1bmRlcnN0YW5kaW5nLg0KPiA+PiA+PiA+Pg0KPiA+
PiA+PiA+DQo+ID4+ID4+ID4gQ09SRV9DKl9SRVNJREVOQ1kgYXJlIGF2YWlsYWJsZSBmb3IgcGh5
c2ljYWwgcHJvY2Vzc29yIGNvcmUuDQo+ID4+ID4+ID4gU28gbG9naWNhbCBwcm9jZXNzb3IgaW4g
c2FtZSBwaHlzaWNhbCBwcm9jZXNzb3IgY29yZSBzaGFyZSB0aGUNCj4gPj4gPj4gPiBzYW1lIGNv
dW50ZXIuDQo+ID4+ID4+ID4gSSB0aGluayB3ZSBuZWVkIHRoZSBjcHVtYXNrIHRvIGlkZW50aWZ5
IHRoZSBkZWZhdWx0IGxvZ2ljYWwNCj4gPj4gPj4gPiBwcm9jZXNzb3Igd2hpY2ggZG8gY291bnRp
bmcuDQo+ID4+ID4+ID4NCj4gPj4gPj4gRGlkIHlvdSByZXN0cmljdCB0aGVzZSBldmVudHMgdG8g
c3lzdGVtLXdpZGUgbW9kZSBvbmx5Pw0KPiA+PiA+Pg0KPiA+PiBPaywgc28gdGhhdCBtZWFucyB0
aGF0IHlvdXIgY3B1bWFzayBpbmNsdWRlcyBvbmUgSFQgcGVyIHBoeXNpY2FsIGNvcmUuDQo+ID4+
IEJ1dCB0aGVuLCB0aGUgcmVzdWx0IGlzIG5vdCB0aGUgc2ltcGxlIGFnZ3JlZ2F0aW9uIG9mIGFs
bCB0aGUgTi8yIENQVXMuDQo+ID4NCj4gPiBUaGUgY291bnRlciBjb3VudHMgcGVyIHBoeXNpY2Fs
IGNvcmUuIFRoZSByZXN1bHQgaXMgdGhlIGFnZ3JlZ2F0aW9uIG9mDQo+ID4gYWxsIEhUIGNwdXMg
aW4gc2FtZSBwaHlzaWNhbCBjb3JlLg0KPiANCj4gQnV0IHRoZW4gZG9uJ3QgeW91IG5lZWQgdG8g
ZGl2aWRlIGJ5IDIgdG8gZ2V0IGEgbWVhbmluZ2Z1bCByZXN1bHQ/DQoNClJldGhpbmsgb2YgaXQu
IEkgdGhpbmsgSSB3YXMgdW5jbGVhciBhYm91dCB0aGUgYWdncmVnYXRpb24gb2YgYWxsIEhUIGNw
dXMNCmluIHNhbWUgcGh5c2ljYWwgY29yZS4NCg0KcGh5c2ljYWwgY29yZSBDc3RhdGUgc2hvdWxk
IGVxdWFsIHRvIG1pbihsb2dpY2FsIGNvcmUgQy1zdGF0ZSkuDQpTbyBvbmx5IGFsbCBsb2dpY2Fs
IGNvcmUgZW50ZXJzIEM2LXN0YXRlLCB0aGUgcGh5c2ljYWwgY29yZSBlbnRlcnMgQzYtc3RhdGUs
DQp0aGVuIENPUkVfQzZfUkVTSURFTkNZIGNvdW50cy4NCg0KU28gaWYgd2Ugb25seSBjb3VudCBv
biBvbmUgbG9naWNhbCBjb3JlL0hUIGZvciBDT1JFX0M2X1JFU0lERU5DWS4NCldlIGRvbid0IG5l
ZWQgdG8gZGl2aWRlIGJ5IDIuIFRoZSBjb3VudCByZXN1bHQgaXMgdGhlIHJlc2lkZW5jeSB3aGVu
IGFsbCBsb2dpY2FsDQpjb3JlIGluIEM2IChzb21lIG1heSBkZWVwZXIpLg0KDQpUaGFua3MsDQpL
YW4NCg0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1202157

FromStephane Eranian <eranian@google.com>
Date2015-08-07 01:20 +0200
Message-ID<pUCC5-6KD-1@gated-at.bofh.it>
In reply to#1202097
On Thu, Aug 6, 2015 at 2:45 PM, Liang, Kan <kan.liang@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Stephane Eranian [mailto:eranian@google.com]
>> Sent: Thursday, August 06, 2015 4:38 PM
>> To: Liang, Kan
>> Cc: Peter Zijlstra; mingo@redhat.com; Arnaldo Carvalho de Melo;
>> ak@linux.intel.com; LKML
>> Subject: Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs
>> support
>>
>> On Thu, Aug 6, 2015 at 1:25 PM, Liang, Kan <kan.liang@intel.com> wrote:
>> >
>> >> >> >> >> +static cpumask_t power_cstate_core_cpu_mask;
>> >> >> >> >
>> >> >> >> > That one typically does not need a cpumask.
>> >> >> >> >
>> >> >> >> You need to pick one CPU out of the multi-core. But it is for
>> >> >> >> client parts thus there is only one socket. At least this is my
>> >> understanding.
>> >> >> >>
>> >> >> >
>> >> >> > CORE_C*_RESIDENCY are available for physical processor core.
>> >> >> > So logical processor in same physical processor core share the
>> >> >> > same counter.
>> >> >> > I think we need the cpumask to identify the default logical
>> >> >> > processor which do counting.
>> >> >> >
>> >> >> Did you restrict these events to system-wide mode only?
>> >> >>
>> >> Ok, so that means that your cpumask includes one HT per physical core.
>> >> But then, the result is not the simple aggregation of all the N/2 CPUs.
>> >
>> > The counter counts per physical core. The result is the aggregation of
>> > all HT cpus in same physical core.
>>
>> But then don't you need to divide by 2 to get a meaningful result?
>
> Rethink of it. I think I was unclear about the aggregation of all HT cpus
> in same physical core.
>
> physical core Cstate should equal to min(logical core C-state).
> So only all logical core enters C6-state, the physical core enters C6-state,
> then CORE_C6_RESIDENCY counts.
>
> So if we only count on one logical core/HT for CORE_C6_RESIDENCY.
> We don't need to divide by 2. The count result is the residency when all logical
> core in C6 (some may deeper).
>
Ok and here you are assuming you are only measuring one logical CPU per
physical core. If this is the case, then I think you are alright. But
I wonder what
you'd get when perf stat -a aggregates across all measured CPUs, i.e., one CPU
per core.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1202162

From"Liang, Kan" <kan.liang@intel.com>
Date2015-08-07 01:50 +0200
Message-ID<pUD58-7hG-1@gated-at.bofh.it>
In reply to#1202157
DQoNCj4gPj4gT24gVGh1LCBBdWcgNiwgMjAxNSBhdCAxOjI1IFBNLCBMaWFuZywgS2FuIDxrYW4u
bGlhbmdAaW50ZWwuY29tPiB3cm90ZToNCj4gPj4gPg0KPiA+PiA+PiA+PiA+PiA+PiArc3RhdGlj
IGNwdW1hc2tfdCBwb3dlcl9jc3RhdGVfY29yZV9jcHVfbWFzazsNCj4gPj4gPj4gPj4gPj4gPg0K
PiA+PiA+PiA+PiA+PiA+IFRoYXQgb25lIHR5cGljYWxseSBkb2VzIG5vdCBuZWVkIGEgY3B1bWFz
ay4NCj4gPj4gPj4gPj4gPj4gPg0KPiA+PiA+PiA+PiA+PiBZb3UgbmVlZCB0byBwaWNrIG9uZSBD
UFUgb3V0IG9mIHRoZSBtdWx0aS1jb3JlLiBCdXQgaXQgaXMNCj4gPj4gPj4gPj4gPj4gZm9yIGNs
aWVudCBwYXJ0cyB0aHVzIHRoZXJlIGlzIG9ubHkgb25lIHNvY2tldC4gQXQgbGVhc3QNCj4gPj4g
Pj4gPj4gPj4gdGhpcyBpcyBteQ0KPiA+PiA+PiB1bmRlcnN0YW5kaW5nLg0KPiA+PiA+PiA+PiA+
Pg0KPiA+PiA+PiA+PiA+DQo+ID4+ID4+ID4+ID4gQ09SRV9DKl9SRVNJREVOQ1kgYXJlIGF2YWls
YWJsZSBmb3IgcGh5c2ljYWwgcHJvY2Vzc29yIGNvcmUuDQo+ID4+ID4+ID4+ID4gU28gbG9naWNh
bCBwcm9jZXNzb3IgaW4gc2FtZSBwaHlzaWNhbCBwcm9jZXNzb3IgY29yZSBzaGFyZQ0KPiA+PiA+
PiA+PiA+IHRoZSBzYW1lIGNvdW50ZXIuDQo+ID4+ID4+ID4+ID4gSSB0aGluayB3ZSBuZWVkIHRo
ZSBjcHVtYXNrIHRvIGlkZW50aWZ5IHRoZSBkZWZhdWx0IGxvZ2ljYWwNCj4gPj4gPj4gPj4gPiBw
cm9jZXNzb3Igd2hpY2ggZG8gY291bnRpbmcuDQo+ID4+ID4+ID4+ID4NCj4gPj4gPj4gPj4gRGlk
IHlvdSByZXN0cmljdCB0aGVzZSBldmVudHMgdG8gc3lzdGVtLXdpZGUgbW9kZSBvbmx5Pw0KPiA+
PiA+PiA+Pg0KPiA+PiA+PiBPaywgc28gdGhhdCBtZWFucyB0aGF0IHlvdXIgY3B1bWFzayBpbmNs
dWRlcyBvbmUgSFQgcGVyIHBoeXNpY2FsDQo+IGNvcmUuDQo+ID4+ID4+IEJ1dCB0aGVuLCB0aGUg
cmVzdWx0IGlzIG5vdCB0aGUgc2ltcGxlIGFnZ3JlZ2F0aW9uIG9mIGFsbCB0aGUgTi8yIENQVXMu
DQo+ID4+ID4NCj4gPj4gPiBUaGUgY291bnRlciBjb3VudHMgcGVyIHBoeXNpY2FsIGNvcmUuIFRo
ZSByZXN1bHQgaXMgdGhlIGFnZ3JlZ2F0aW9uDQo+ID4+ID4gb2YgYWxsIEhUIGNwdXMgaW4gc2Ft
ZSBwaHlzaWNhbCBjb3JlLg0KPiA+Pg0KPiA+PiBCdXQgdGhlbiBkb24ndCB5b3UgbmVlZCB0byBk
aXZpZGUgYnkgMiB0byBnZXQgYSBtZWFuaW5nZnVsIHJlc3VsdD8NCj4gPg0KPiA+IFJldGhpbmsg
b2YgaXQuIEkgdGhpbmsgSSB3YXMgdW5jbGVhciBhYm91dCB0aGUgYWdncmVnYXRpb24gb2YgYWxs
IEhUDQo+ID4gY3B1cyBpbiBzYW1lIHBoeXNpY2FsIGNvcmUuDQo+ID4NCj4gPiBwaHlzaWNhbCBj
b3JlIENzdGF0ZSBzaG91bGQgZXF1YWwgdG8gbWluKGxvZ2ljYWwgY29yZSBDLXN0YXRlKS4NCj4g
PiBTbyBvbmx5IGFsbCBsb2dpY2FsIGNvcmUgZW50ZXJzIEM2LXN0YXRlLCB0aGUgcGh5c2ljYWwg
Y29yZSBlbnRlcnMNCj4gPiBDNi1zdGF0ZSwgdGhlbiBDT1JFX0M2X1JFU0lERU5DWSBjb3VudHMu
DQo+ID4NCj4gPiBTbyBpZiB3ZSBvbmx5IGNvdW50IG9uIG9uZSBsb2dpY2FsIGNvcmUvSFQgZm9y
IENPUkVfQzZfUkVTSURFTkNZLg0KPiA+IFdlIGRvbid0IG5lZWQgdG8gZGl2aWRlIGJ5IDIuIFRo
ZSBjb3VudCByZXN1bHQgaXMgdGhlIHJlc2lkZW5jeSB3aGVuDQo+ID4gYWxsIGxvZ2ljYWwgY29y
ZSBpbiBDNiAoc29tZSBtYXkgZGVlcGVyKS4NCj4gPg0KPiBPayBhbmQgaGVyZSB5b3UgYXJlIGFz
c3VtaW5nIHlvdSBhcmUgb25seSBtZWFzdXJpbmcgb25lIGxvZ2ljYWwgQ1BVIHBlcg0KPiBwaHlz
aWNhbCBjb3JlLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVuIEkgdGhpbmsgeW91IGFyZSBhbHJp
Z2h0LiBCdXQgSSB3b25kZXINCj4gd2hhdCB5b3UnZCBnZXQgd2hlbiBwZXJmIHN0YXQgLWEgYWdn
cmVnYXRlcyBhY3Jvc3MgYWxsIG1lYXN1cmVkIENQVXMsIGkuZS4sDQo+IG9uZSBDUFUgcGVyIGNv
cmUuDQoNCkp1c3QgYWRkIHRoZW0gYWxsIHRvZ2V0aGVyLg0KSSB0aGluayB3ZSBkbyB0aGUgc2Ft
ZSB0aGluZyBmb3Igb3RoZXIgUE1VcyBhcyB3ZWxsLg0KRm9yIHVuY29yZSBvciByYXBsLCB3ZSBn
ZXQgbWVhbmluZ2Z1bCByZXN1bHQgYnkgYXBwbHlpbmcgLS1wZXItc29ja2V0Lg0KSGVyZSB3ZSBj
YW4gdXNlIC0tcGVyLWNvcmUuIA0KDQpUaGFua3MsDQpLYW4NCg0KDQoNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1202094

FromPeter Zijlstra <peterz@infradead.org>
Date2015-08-06 23:40 +0200
Message-ID<pUB3k-4qt-33@gated-at.bofh.it>
In reply to#1201959
On Thu, Aug 06, 2015 at 11:14:17AM -0700, Stephane Eranian wrote:
> On Thu, Aug 6, 2015 at 8:44 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >> +static cpumask_t power_cstate_core_cpu_mask;
> >
> > That one typically does not need a cpumask.
> >
> You need to pick one CPU out of the multi-core. But it is for client parts thus
> there is only one socket. At least this is my understanding.

Oh crud, core as in a group of SMT. There's so much core as in logical
cpu usage around these days I got confused :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web