| Message ID | 1374162523-2777-1-git-send-email-dirk.j.brandewie@gmail.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Thu, Jul 18, 2013 at 9:18 PM, <dirk.brandewie@gmail.com> wrote: > From: Dirk Brandewie <dirk.j.brandewie@intel.com> > > Change to using max P-state instead of max turbo P-state. This change > resolves two issues. > > On a quiet system intel_pstate can fail to respond to a load change. > https://bugzilla.kernel.org/show_bug.cgi?id=59481 > > On CPU SKUs that have a limited number of P-states and no turbo range > intel_pstate fails to select the highest available P-state. > > This change is suitable for stable v3.9+ > > Reported-by: arjan@linux.intel.com > Reported-by: dsmythies@telus.net > Tested-by: arjan@linux.intel.com > Tested-by: dsmythies@telus.net > > CC: stable@vger.kernel.org > CC: dsmythies@telus.net > Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> > --- > drivers/cpufreq/intel_pstate.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
<dirk.brandewie <at> gmail.com> writes: > > From: Dirk Brandewie <dirk.j.brandewie <at> intel.com> > > Change to using max P-state instead of max turbo P-state. This change > resolves two issues. > > On a quiet system intel_pstate can fail to respond to a load change. > https://bugzilla.kernel.org/show_bug.cgi?id=59481 > > On CPU SKUs that have a limited number of P-states and no turbo range > intel_pstate fails to select the highest available P-state. > > This change is suitable for stable v3.9+ > > Reported-by: arjan <at> linux.intel.com > Reported-by: dsmythies <at> telus.net > Tested-by: arjan <at> linux.intel.com > Tested-by: dsmythies <at> telus.net > > CC: stable <at> vger.kernel.org > CC: dsmythies <at> telus.net > Signed-off-by: Dirk Brandewie <dirk.j.brandewie <at> intel.com> Hi, I've just tested the patch and, even though it works (the frequency now sits around 1.3-1.5 GHz), I noticed that if I suspend the laptop and then resume it, the abnormal behavior (frequency sitting above 2 GHz) returns. Before suspending, the value in /sys/devices/system/cpu/intel_pstate/min_perf_pct was 37; afterwards, 100. cpuinfo: http://pastebin.com/C6zR90HC I'd be glad to give any further details. Best, Guilherme -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/01/2013 10:56 AM, Guilherme Salazar wrote: > <dirk.brandewie <at> gmail.com> writes: > >> >> From: Dirk Brandewie <dirk.j.brandewie <at> intel.com> >> >> Change to using max P-state instead of max turbo P-state. This change >> resolves two issues. >> >> On a quiet system intel_pstate can fail to respond to a load change. >> https://bugzilla.kernel.org/show_bug.cgi?id=59481 >> >> On CPU SKUs that have a limited number of P-states and no turbo range >> intel_pstate fails to select the highest available P-state. >> >> This change is suitable for stable v3.9+ >> >> Reported-by: arjan <at> linux.intel.com >> Reported-by: dsmythies <at> telus.net >> Tested-by: arjan <at> linux.intel.com >> Tested-by: dsmythies <at> telus.net >> >> CC: stable <at> vger.kernel.org >> CC: dsmythies <at> telus.net >> Signed-off-by: Dirk Brandewie <dirk.j.brandewie <at> intel.com> > > Hi, > > I've just tested the patch and, even though it works (the frequency now sits > around 1.3-1.5 GHz), I noticed that if I suspend the laptop and then resume > it, the abnormal behavior (frequency sitting above 2 GHz) returns. > There is a separate bug against the suspend resume behaviour. It is coming from a bug in the cpufreq core. https://bugzilla.kernel.org/show_bug.cgi?id=59781 The fix is disscussed in https://lkml.org/lkml/2013/7/29/692 and is queue for 3.12 > Before suspending, the value in > /sys/devices/system/cpu/intel_pstate/min_perf_pct was 37; afterwards, 100. > > cpuinfo: http://pastebin.com/C6zR90HC > > I'd be glad to give any further details. > > Best, > Guilherme > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 07f2840..6d6a0b4 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -103,10 +103,10 @@ struct pstate_adjust_policy { static struct pstate_adjust_policy default_policy = { .sample_rate_ms = 10, .deadband = 0, - .setpoint = 109, - .p_gain_pct = 17, + .setpoint = 97, + .p_gain_pct = 20, .d_gain_pct = 0, - .i_gain_pct = 4, + .i_gain_pct = 0, }; struct perf_limits { @@ -468,12 +468,12 @@ static inline void intel_pstate_set_sample_time(struct cpudata *cpu) static inline int intel_pstate_get_scaled_busy(struct cpudata *cpu) { int32_t busy_scaled; - int32_t core_busy, turbo_pstate, current_pstate; + int32_t core_busy, max_pstate, current_pstate; core_busy = int_tofp(cpu->samples[cpu->sample_ptr].core_pct_busy); - turbo_pstate = int_tofp(cpu->pstate.turbo_pstate); + max_pstate = int_tofp(cpu->pstate.max_pstate); current_pstate = int_tofp(cpu->pstate.current_pstate); - busy_scaled = mul_fp(core_busy, div_fp(turbo_pstate, current_pstate)); + busy_scaled = mul_fp(core_busy, div_fp(max_pstate, current_pstate)); return fp_toint(busy_scaled); }