Re: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct

On 13/06/2014 04:48 μμ, Dirk Brandewie wrote: > On 06/12/2014 01:03 PM, Rafael J. Wysocki wrote: >> On Thursday, June 12, 2014 05:35:59 PM Stratos Karafotis wrote: >>> On 12/06/2014 12:15 πμ, Doug Smythies wrote: >>>> >>>> >>>> -Original M

Re: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct

On 13/06/2014 09:49 πμ, Doug Smythies wrote: > On 2014.06.12 13:03 Rafael J. Wysocki wrote: >> On Thursday, June 12, 2014 05:35:59 PM Stratos Karafotis wrote: >>> On 12/06/2014 12:15 πμ, Doug Smythies wrote: >>>> >>>> >>>> On 2014.06.11 13:20

[PATCH] cpufreq: intel_pstate: Remove unused member name of cpudata

Although, a value is assigned to member name of struct cpudata, it is never used. We can safely remove it. Signed-off-by: Stratos Karafotis --- drivers/cpufreq/intel_pstate.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c

[RFC PATCH] cpufreq: intel_pstate: Change the calculation of next pstate

56 and the decrease in energy consumption ~7.96% Signed-off-by: Stratos Karafotis --- Detailed test results can be found in this link: https://docs.google.com/spreadsheets/d/1xiw8FOswoNFA8seNMz0nYUdhjPPvJ8J2S54kG02dOP8/edit?usp=sharing drivers/cpufreq/intel_psta

Re: [PATCH v5 0/8] Introduce new cpufreq helper macros

Hi all, On 06/05/2014 06:24 μμ, Geert Uytterhoeven wrote: > Hi Stratos, > > On Wed, Apr 30, 2014 at 12:26 AM, Rafael J. Wysocki > wrote: >> On Tuesday, April 29, 2014 07:05:17 PM Stratos Karafotis wrote: >>> On 29/04/2014 07:17 πμ, Viresh Kumar wrote: >>&

Re: [PATCH v5 0/8] Introduce new cpufreq helper macros

Hi Rafael, On 07/05/2014 04:13 μμ, Rafael J. Wysocki wrote: > On Wednesday, May 07, 2014 10:53:16 AM Viresh Kumar wrote: >> On 6 May 2014 23:25, Stratos Karafotis wrote: >>> My bad. I'm sorry for this. :( >>> >>> Rafael, >>> A solution could b

[PATCH] cpufreq: Fix build error on some platforms that use cpufreq_for_each_*

n function `clk_rate_table_find': clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid' make[3]: *** [vmlinux] Error 1 Fix this making cpufreq_next_valid function inline and move it to cpufreq.h. Reported-by: Geert Uytterhoeven Signed-off-by: Stratos Karafotis --- drivers/cp

Re: [PATCH 2/7] cpufreq: intel_pstate: Avoid duplicate call of intel_pstate_get_scaled_busy

On 14/06/2014 06:45 μμ, Doug Smythies wrote: > I am sorry to be late chiming in on this one. > > On 2014.06.10 09:27 Stratos Karafotis wrote: >> On 10/06/2014 07:05 μμ, Dirk Brandewie wrote: >> On 06/09/2014 02:00 PM, Stratos Karafotis wrote: >>> Store busy_scaled va

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

Hi, Thanks for reviewing. On 07/11/2016 08:12 πμ, Viresh Kumar wrote: > For the record, I have never got the original mail with this subject. I'm sorry for inconvenience. It seems that I had an issue on my mail server. > On 06-11-16, 11:19, Stratos Karafotis wrote: >> Cons

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

On 08/11/2016 10:32 πμ, Viresh Kumar wrote: > On 8 November 2016 at 12:49, Stratos Karafotis wrote: >> I think we shouldn't. That's why the patch first decreases the frequency >> by n freq steps (where n the number of deferred periods). >> Then the normal processin

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

On 09/11/2016 07:55 πμ, Viresh Kumar wrote: > On 08-11-16, 21:25, Stratos Karafotis wrote: >> But this is the supposed behaviour of conservative governor. We want >> the CPU to increase the frequency in steps. The patch just resets >> the frequency to a lower frequency in ca

[PATCH v4] cpufreq: conservative: Decrease frequency faster when the update deferred

frequency after 0.86s Signed-off-by: Stratos Karafotis Acked-by: Viresh Kumar --- v3 -> v4 - Fix format issues - Ack by Viresh Kumar v2 -> v3 - cpufreq_conservative.c: move the calculation below the block that check the limits - Calculate the freq_step only once - Fix the bug introduced in dbs_

[PATCH] cpufreq: conservative: Fix comment explaining frequency updates

The original comment about the frequency increase to maximum is wrong. Both increase and decrease happen at steps. Signed-off-by: Stratos Karafotis --- drivers/cpufreq/cpufreq_conservative.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq

[PATCH v2] cpufreq: conservative: Fix comment explaining frequency updates

The original comment about the frequency increase to maximum is wrong. Both increase and decrease happen at steps. Signed-off-by: Stratos Karafotis --- -> v2 Remove a trailing space drivers/cpufreq/cpufreq_conservative.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --gi

[RFC][PATCH] cpufreq: governor: Change the calculation of load for deferred updates

me_elapsed - idle_time and load = 100 * busy / sampling_rate; Also, remove the 'unlikely' hint because it seems that a deferred update is a very common case on most modern systems. Signed-off-by: Stratos Karafotis --- drivers/cpufreq/cpufreq_governor.c | 37 +++---

Re: [PATCH v2] cpufreq: conservative: Decrease frequency faster when the update deferred

On 14/11/2016 10:44 μμ, Rafael J. Wysocki wrote: > On Sat, Nov 12, 2016 at 10:04 PM, Stratos Karafotis > wrote: >> Conservative governor changes the CPU frequency in steps. >> That means that if a CPU runs at max frequency, it will need several >> sampling periods to

Re: [PATCH v2] cpufreq: conservative: Decrease frequency faster when the update deferred

On 15/11/2016 12:09 πμ, Rafael J. Wysocki wrote: > On Mon, Nov 14, 2016 at 10:59 PM, Rafael J. Wysocki wrote: >> On Mon, Nov 14, 2016 at 10:46 PM, Stratos Karafotis >> wrote: >>> >>> >>> On 14/11/2016 10:44 μμ, Rafael J. Wysocki wrote: >>>&g

[PATCH v3] cpufreq: conservative: Decrease frequency faster when the update deferred

frequency after 0.86s Signed-off-by: Stratos Karafotis --- v2 -> v3 - cpufreq_conservative.c: move the calculation below the block that check the limits - Calculate the freq_step only once - Fix the bug introduced in dbs_update() because of wrong estimation of 'if' conditions v1 ->

[PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

after 0.86s Signed-off-by: Stratos Karafotis --- drivers/cpufreq/cpufreq_conservative.c | 9 + drivers/cpufreq/cpufreq_governor.c | 18 +- drivers/cpufreq/cpufreq_governor.h | 1 + 3 files changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/cpufreq

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

On 10/11/2016 02:13 πμ, Rafael J. Wysocki wrote: > On Wed, Nov 9, 2016 at 6:55 AM, Viresh Kumar wrote: >> On 08-11-16, 21:25, Stratos Karafotis wrote: >>> But this is the supposed behaviour of conservative governor. We want >>> the CPU to increase the frequency in s

[PATCH v2] cpufreq: conservative: Decrease frequency faster when the update deferred

frequency after 0.86s Signed-off-by: Stratos Karafotis --- v1 -> v2 - Use correct terminology in change log - Change the member variable name from 'deferred_periods' to 'idle_periods' - Fix format issue drivers/cpufreq/cpufreq_conservative.c | 14 +- drivers/cpu

[Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

after 0.86s Signed-off-by: Stratos Karafotis --- drivers/cpufreq/cpufreq_conservative.c | 9 + drivers/cpufreq/cpufreq_governor.c | 18 +- drivers/cpufreq/cpufreq_governor.h | 1 + 3 files changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/cpufreq

Re: [PATCH 1/1] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

Hi, On 16/09/2016 12:47 μμ, Andreas Herrmann wrote: > On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote: >> On 01-09-16, 15:21, Andreas Herrmann wrote: >>> On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote: > I am _really_ worried about such hacks in drivers to negate t

<    1   2   3