Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1410613 > unrolled thread
| Started by | Jacob Pan <jacob.jun.pan@linux.intel.com> |
|---|---|
| First post | 2016-05-31 22:50 +0200 |
| Last post | 2016-05-31 22:50 +0200 |
| Articles | 6 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH 0/2] Powercap RAPL update for Denverton Jacob Pan <jacob.jun.pan@linux.intel.com> - 2016-05-31 22:50 +0200
[PATCH 2/2] powercap/rapl: add support for denverton Jacob Pan <jacob.jun.pan@linux.intel.com> - 2016-05-31 22:50 +0200
Re: [PATCH 2/2] powercap/rapl: add support for denverton Dave Hansen <dave.hansen@intel.com> - 2016-06-01 00:20 +0200
Re: [PATCH 2/2] powercap/rapl: add support for denverton Thomas Gleixner <tglx@linutronix.de> - 2016-06-01 09:00 +0200
Re: [PATCH 2/2] powercap/rapl: add support for denverton Jacob Pan <jacob.jun.pan@linux.intel.com> - 2016-06-01 17:20 +0200
[PATCH 1/2] powercap/rapl: handle missing msrs Jacob Pan <jacob.jun.pan@linux.intel.com> - 2016-05-31 22:50 +0200
| From | Jacob Pan <jacob.jun.pan@linux.intel.com> |
|---|---|
| Date | 2016-05-31 22:50 +0200 |
| Subject | [PATCH 0/2] Powercap RAPL update for Denverton |
| Message-ID | <rEYLT-7qa-11@gated-at.bofh.it> |
A few MSRs are missing from Denverton RAPL interface which makes domain detection fail prematurely. The patchset adds flexibility to the detection logic such that it will support what functionality remains available. Jacob Pan (2): powercap/rapl: handle missing msrs powercap/rapl: add support for denverton drivers/powercap/intel_rapl.c | 104 ++++++++++++++++++++++++++++++++---------- 1 file changed, 80 insertions(+), 24 deletions(-) -- 1.9.1
[toc] | [next] | [standalone]
| From | Jacob Pan <jacob.jun.pan@linux.intel.com> |
|---|---|
| Date | 2016-05-31 22:50 +0200 |
| Subject | [PATCH 2/2] powercap/rapl: add support for denverton |
| Message-ID | <rEYLT-7qa-15@gated-at.bofh.it> |
| In reply to | #1410613 |
Denverton micro server is Atom based but RAPL interface
is compatible with Core based CPUs.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
---
drivers/powercap/intel_rapl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index d51a8d4..f0fc1a3 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -1137,6 +1137,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
RAPL_CPU(0x57, rapl_defaults_hsw_server),/* Knights Landing */
RAPL_CPU(0x8E, rapl_defaults_core),/* Kabylake */
RAPL_CPU(0x9E, rapl_defaults_core),/* Kabylake */
+ RAPL_CPU(0x5F, rapl_defaults_core),/* Denverton micro server */
{}
};
MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
--
1.9.1
[toc] | [prev] | [next] | [standalone]
| From | Dave Hansen <dave.hansen@intel.com> |
|---|---|
| Date | 2016-06-01 00:20 +0200 |
| Subject | Re: [PATCH 2/2] powercap/rapl: add support for denverton |
| Message-ID | <rF0aZ-8nI-5@gated-at.bofh.it> |
| In reply to | #1410615 |
On 05/31/2016 01:41 PM, Jacob Pan wrote:
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -1137,6 +1137,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
> RAPL_CPU(0x57, rapl_defaults_hsw_server),/* Knights Landing */
> RAPL_CPU(0x8E, rapl_defaults_core),/* Kabylake */
> RAPL_CPU(0x9E, rapl_defaults_core),/* Kabylake */
> + RAPL_CPU(0x5F, rapl_defaults_core),/* Denverton micro server */
> {}
> };
Not to derail this individual patch... but do we really want to continue
open-coding CPU model/family combos all over arch/x86?
For instance, arch/x86/events/intel/core.c has:
> case 142: /* 14nm Kabylake Mobile */
> case 158: /* 14nm Kabylake Desktop */
> case 78: /* 14nm Skylake Mobile */
> case 94: /* 14nm Skylake Desktop */
> case 85: /* 14nm Skylake Server */
Which duplicates the two Kabylake family numbers from the RAPL_CPU()
context above (just in decimal instead of hex).
Should we just start sticking these things in a header like:
#define X86_INTEL_FAMILY_KABYLAKE1 0x8E
#define X86_INTEL_FAMILY_KABYLAKE2 0x9E
#define X86_INTEL_FAMILY_DENVERTON 0x5F
So we have this:
RAPL_CPU(X86_INTEL_FAMILY_DENVERTON, rapl_defaults_core),
instead of having to explain our magic number in a comment.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2016-06-01 09:00 +0200 |
| Subject | Re: [PATCH 2/2] powercap/rapl: add support for denverton |
| Message-ID | <rF8id-51y-17@gated-at.bofh.it> |
| In reply to | #1410663 |
On Tue, 31 May 2016, Dave Hansen wrote:
> On 05/31/2016 01:41 PM, Jacob Pan wrote:
> > --- a/drivers/powercap/intel_rapl.c
> > +++ b/drivers/powercap/intel_rapl.c
> > @@ -1137,6 +1137,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
> > RAPL_CPU(0x57, rapl_defaults_hsw_server),/* Knights Landing */
> > RAPL_CPU(0x8E, rapl_defaults_core),/* Kabylake */
> > RAPL_CPU(0x9E, rapl_defaults_core),/* Kabylake */
> > + RAPL_CPU(0x5F, rapl_defaults_core),/* Denverton micro server */
> > {}
> > };
>
> Not to derail this individual patch... but do we really want to continue
> open-coding CPU model/family combos all over arch/x86?
>
> For instance, arch/x86/events/intel/core.c has:
>
> > case 142: /* 14nm Kabylake Mobile */
> > case 158: /* 14nm Kabylake Desktop */
> > case 78: /* 14nm Skylake Mobile */
> > case 94: /* 14nm Skylake Desktop */
> > case 85: /* 14nm Skylake Server */
>
> Which duplicates the two Kabylake family numbers from the RAPL_CPU()
> context above (just in decimal instead of hex).
>
> Should we just start sticking these things in a header like:
>
> #define X86_INTEL_FAMILY_KABYLAKE1 0x8E
> #define X86_INTEL_FAMILY_KABYLAKE2 0x9E
> #define X86_INTEL_FAMILY_DENVERTON 0x5F
>
> So we have this:
>
> RAPL_CPU(X86_INTEL_FAMILY_DENVERTON, rapl_defaults_core),
>
> instead of having to explain our magic number in a comment.
Yes please.
[toc] | [prev] | [next] | [standalone]
| From | Jacob Pan <jacob.jun.pan@linux.intel.com> |
|---|---|
| Date | 2016-06-01 17:20 +0200 |
| Subject | Re: [PATCH 2/2] powercap/rapl: add support for denverton |
| Message-ID | <rFg66-1A8-19@gated-at.bofh.it> |
| In reply to | #1410875 |
On Wed, 1 Jun 2016 08:57:27 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 31 May 2016, Dave Hansen wrote:
> > On 05/31/2016 01:41 PM, Jacob Pan wrote:
> > > --- a/drivers/powercap/intel_rapl.c
> > > +++ b/drivers/powercap/intel_rapl.c
> > > @@ -1137,6 +1137,7 @@ static const struct x86_cpu_id rapl_ids[]
> > > __initconst = { RAPL_CPU(0x57, rapl_defaults_hsw_server),/*
> > > Knights Landing */ RAPL_CPU(0x8E, rapl_defaults_core),/* Kabylake
> > > */ RAPL_CPU(0x9E, rapl_defaults_core),/* Kabylake */
> > > + RAPL_CPU(0x5F, rapl_defaults_core),/* Denverton micro
> > > server */ {}
> > > };
> >
> > Not to derail this individual patch... but do we really want to
> > continue open-coding CPU model/family combos all over arch/x86?
> >
> > For instance, arch/x86/events/intel/core.c has:
> >
> > > case 142: /* 14nm Kabylake Mobile */
> > > case 158: /* 14nm Kabylake Desktop */
> > > case 78: /* 14nm Skylake Mobile */
> > > case 94: /* 14nm Skylake Desktop */
> > > case 85: /* 14nm Skylake Server */
> >
> > Which duplicates the two Kabylake family numbers from the RAPL_CPU()
> > context above (just in decimal instead of hex).
> >
> > Should we just start sticking these things in a header like:
> >
> > #define X86_INTEL_FAMILY_KABYLAKE1 0x8E
> > #define X86_INTEL_FAMILY_KABYLAKE2 0x9E
> > #define X86_INTEL_FAMILY_DENVERTON 0x5F
> >
> > So we have this:
> >
> > RAPL_CPU(X86_INTEL_FAMILY_DENVERTON, rapl_defaults_core),
> >
> > instead of having to explain our magic number in a comment.
>
> Yes please.
This open coding also applies to other x86 vendors. I can make change
for Intel since in some case, there is not even a comment about
what the model is. e.g.
in amd_nb.h
(boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model < 0x10))
Should the model numbers be in
arch/x86/include/asm/processor.h?
[toc] | [prev] | [next] | [standalone]
| From | Jacob Pan <jacob.jun.pan@linux.intel.com> |
|---|---|
| Date | 2016-05-31 22:50 +0200 |
| Subject | [PATCH 1/2] powercap/rapl: handle missing msrs |
| Message-ID | <rEYLT-7qa-23@gated-at.bofh.it> |
| In reply to | #1410613 |
Some RAPL MSRs may not exist on some CPUs, we need to continue
the topology detection and enumerate what is available.
This patch handles the missing MSRs then report to powercap
layer only the features available.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
---
drivers/powercap/intel_rapl.c | 103 ++++++++++++++++++++++++++++++++----------
1 file changed, 79 insertions(+), 24 deletions(-)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index b0a2dc4..d51a8d4 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -329,14 +329,14 @@ static int release_zone(struct powercap_zone *power_zone)
static int find_nr_power_limit(struct rapl_domain *rd)
{
- int i;
+ int i, nr_pl = 0;
for (i = 0; i < NR_POWER_LIMITS; i++) {
- if (rd->rpl[i].name == NULL)
- break;
+ if (rd->rpl[i].name)
+ nr_pl++;
}
- return i;
+ return nr_pl;
}
static int set_domain_enable(struct powercap_zone *power_zone, bool mode)
@@ -411,15 +411,38 @@ static const struct powercap_zone_ops zone_ops[] = {
},
};
-static int set_power_limit(struct powercap_zone *power_zone, int id,
+
+/*
+ * Constraint index used by powercap can be different than power limit (PL)
+ * index in that some PLs maybe missing due to non-existant MSRs. So we
+ * need to convert here by finding the valid PLs only (name populated).
+ */
+static int contraint_to_pl(struct rapl_domain *rd, int cid)
+{
+ int i, j;
+
+ for (i = 0, j = 0; i < NR_POWER_LIMITS; i++) {
+ if ((rd->rpl[i].name) && j++ == cid) {
+ pr_debug("%s: index %d\n", __func__, i);
+ return i;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static int set_power_limit(struct powercap_zone *power_zone, int cid,
u64 power_limit)
{
struct rapl_domain *rd;
struct rapl_package *rp;
int ret = 0;
+ int id;
get_online_cpus();
rd = power_zone_to_rapl_domain(power_zone);
+ id = contraint_to_pl(rd, cid);
+
rp = rd->rp;
if (rd->state & DOMAIN_STATE_BIOS_LOCKED) {
@@ -446,16 +469,18 @@ set_exit:
return ret;
}
-static int get_current_power_limit(struct powercap_zone *power_zone, int id,
+static int get_current_power_limit(struct powercap_zone *power_zone, int cid,
u64 *data)
{
struct rapl_domain *rd;
u64 val;
int prim;
int ret = 0;
+ int id;
get_online_cpus();
rd = power_zone_to_rapl_domain(power_zone);
+ id = contraint_to_pl(rd, cid);
switch (rd->rpl[id].prim_id) {
case PL1_ENABLE:
prim = POWER_LIMIT1;
@@ -477,14 +502,17 @@ static int get_current_power_limit(struct powercap_zone *power_zone, int id,
return ret;
}
-static int set_time_window(struct powercap_zone *power_zone, int id,
+static int set_time_window(struct powercap_zone *power_zone, int cid,
u64 window)
{
struct rapl_domain *rd;
int ret = 0;
+ int id;
get_online_cpus();
rd = power_zone_to_rapl_domain(power_zone);
+ id = contraint_to_pl(rd, cid);
+
switch (rd->rpl[id].prim_id) {
case PL1_ENABLE:
rapl_write_data_raw(rd, TIME_WINDOW1, window);
@@ -499,14 +527,17 @@ static int set_time_window(struct powercap_zone *power_zone, int id,
return ret;
}
-static int get_time_window(struct powercap_zone *power_zone, int id, u64 *data)
+static int get_time_window(struct powercap_zone *power_zone, int cid, u64 *data)
{
struct rapl_domain *rd;
u64 val;
int ret = 0;
+ int id;
get_online_cpus();
rd = power_zone_to_rapl_domain(power_zone);
+ id = contraint_to_pl(rd, cid);
+
switch (rd->rpl[id].prim_id) {
case PL1_ENABLE:
ret = rapl_read_data_raw(rd, TIME_WINDOW1, true, &val);
@@ -525,15 +556,17 @@ static int get_time_window(struct powercap_zone *power_zone, int id, u64 *data)
return ret;
}
-static const char *get_constraint_name(struct powercap_zone *power_zone, int id)
+static const char *get_constraint_name(struct powercap_zone *power_zone, int cid)
{
- struct rapl_power_limit *rpl;
struct rapl_domain *rd;
+ int id;
rd = power_zone_to_rapl_domain(power_zone);
- rpl = (struct rapl_power_limit *) &rd->rpl[id];
+ id = contraint_to_pl(rd, cid);
+ if (id >= 0)
+ return rd->rpl[id].name;
- return rpl->name;
+ return NULL;
}
@@ -1305,6 +1338,37 @@ static int rapl_check_domain(int cpu, int domain)
return 0;
}
+
+/*
+ * Check if power limits are available. Two cases when they are not available:
+ * 1. Locked by BIOS, in this case we still provide read-only access so that
+ * users can see what limit is set by the BIOS.
+ * 2. Some CPUs make some domains monitoring only which means PLx MSRs may not
+ * exist at all. In this case, we do not show the contraints in powercap.
+ *
+ * Called after domains are detected and initialized.
+ */
+static void rapl_detect_powerlimit(struct rapl_domain *rd)
+{
+ u64 val64;
+ int i;
+
+ /* check if the domain is locked by BIOS, ignore if MSR doesn't exist */
+ if (!rapl_read_data_raw(rd, FW_LOCK, false, &val64)) {
+ if (val64) {
+ pr_info("RAPL package %d domain %s locked by BIOS\n",
+ rd->rp->id, rd->name);
+ rd->state |= DOMAIN_STATE_BIOS_LOCKED;
+ }
+ }
+ /* check if power limit MSRs exists, otherwise domain is monitoring only */
+ for (i = 0; i < NR_POWER_LIMITS; i++) {
+ int prim = rd->rpl[i].prim_id;
+ if (rapl_read_data_raw(rd, prim, false, &val64))
+ rd->rpl[i].name = NULL;
+ }
+}
+
/* Detect active and valid domains for the given CPU, caller must
* ensure the CPU belongs to the targeted package and CPU hotlug is disabled.
*/
@@ -1313,7 +1377,6 @@ static int rapl_detect_domains(struct rapl_package *rp, int cpu)
int i;
int ret = 0;
struct rapl_domain *rd;
- u64 locked;
for (i = 0; i < RAPL_DOMAIN_MAX; i++) {
/* use physical package id to read counters */
@@ -1338,17 +1401,9 @@ static int rapl_detect_domains(struct rapl_package *rp, int cpu)
}
rapl_init_domains(rp);
- for (rd = rp->domains; rd < rp->domains + rp->nr_domains; rd++) {
- /* check if the domain is locked by BIOS */
- ret = rapl_read_data_raw(rd, FW_LOCK, false, &locked);
- if (ret)
- return ret;
- if (locked) {
- pr_info("RAPL package %d domain %s locked by BIOS\n",
- rp->id, rd->name);
- rd->state |= DOMAIN_STATE_BIOS_LOCKED;
- }
- }
+ for (rd = rp->domains; rd < rp->domains + rp->nr_domains; rd++)
+ rapl_detect_powerlimit(rd);
+
done:
--
1.9.1
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web