* [PATCH] cpufreq/intel_pstate: Change to scale off of max P-state
@ 2013-07-18 15:48 dirk.brandewie
2013-07-19 3:53 ` Viresh Kumar
2013-08-01 17:56 ` Guilherme Salazar
0 siblings, 2 replies; 5+ messages in thread
From: dirk.brandewie @ 2013-07-18 15:48 UTC (permalink / raw)
To: kernel, linux-pm; +Cc: dirk.brandewie, Dirk Brandewie, stable, dsmythies
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(-)
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);
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] cpufreq/intel_pstate: Change to scale off of max P-state
2013-07-18 15:48 [PATCH] cpufreq/intel_pstate: Change to scale off of max P-state dirk.brandewie
@ 2013-07-19 3:53 ` Viresh Kumar
2013-08-01 17:56 ` Guilherme Salazar
1 sibling, 0 replies; 5+ messages in thread
From: Viresh Kumar @ 2013-07-19 3:53 UTC (permalink / raw)
To: dirk.brandewie; +Cc: kernel, linux-pm, Dirk Brandewie, stable, dsmythies
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] cpufreq/intel_pstate: Change to scale off of max P-state
2013-07-18 15:48 [PATCH] cpufreq/intel_pstate: Change to scale off of max P-state dirk.brandewie
2013-07-19 3:53 ` Viresh Kumar
@ 2013-08-01 17:56 ` Guilherme Salazar
2013-08-20 18:37 ` Dirk Brandewie
1 sibling, 1 reply; 5+ messages in thread
From: Guilherme Salazar @ 2013-08-01 17:56 UTC (permalink / raw)
To: linux-pm
<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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] cpufreq/intel_pstate: Change to scale off of max P-state
2013-08-01 17:56 ` Guilherme Salazar
@ 2013-08-20 18:37 ` Dirk Brandewie
0 siblings, 0 replies; 5+ messages in thread
From: Dirk Brandewie @ 2013-08-20 18:37 UTC (permalink / raw)
To: Guilherme Salazar; +Cc: linux-pm, dirk.brandewie
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] cpufreq/intel_pstate: Change to scale off of max P-state
@ 2013-07-18 15:58 dirk.brandewie
0 siblings, 0 replies; 5+ messages in thread
From: dirk.brandewie @ 2013-07-18 15:58 UTC (permalink / raw)
To: linux-kernel; +Cc: Dirk Brandewie, stable, dsmythies
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(-)
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);
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-08-20 18:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-18 15:48 [PATCH] cpufreq/intel_pstate: Change to scale off of max P-state dirk.brandewie
2013-07-19 3:53 ` Viresh Kumar
2013-08-01 17:56 ` Guilherme Salazar
2013-08-20 18:37 ` Dirk Brandewie
2013-07-18 15:58 dirk.brandewie
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.