On 11/07/2014 09:34 μμ, Pavel Machek wrote:
On Fri 2014-07-11 20:29:57, Stratos Karafotis wrote:
Hi Pavel!
On 11/07/2014 07:57 μμ, Pavel Machek wrote:
Hi!
Tested on Intel i7-3770 CPU @ 3.40GHz and on ARM quad core 1500MHz Krait
(Android smartphone).
Benchmarks on Intel i7 shows
On 21/07/2014 12:51 πμ, Pavel Machek wrote:
Hi!
Tested on Intel i7-3770 CPU @ 3.40GHz and on ARM quad core 1500MHz Krait
(Android smartphone).
Benchmarks on Intel i7 shows a performance improvement on low and medium
work loads with lower power consumption. Specifics:
Phoronix Linux Kernel
On 07/23/2014 02:50 AM, Rafael J. Wysocki wrote:
On Monday, June 30, 2014 07:59:32 PM Stratos Karafotis wrote:
Hi all,
This patchset changes slightly the calculation of target frequency to
eliminate the deadband effect (explained in patch 2 changelog) that it
seems to slow down the CPU in low
Introduce CPUFREQ_RELATION_C for frequency selection.
It selects the frequency with the minimum euclidean distance to target.
In case of equal distance between 2 frequencies, it will select the
greater frequency.
Signed-off-by: Stratos Karafotis strat...@semaphore.gr
---
drivers/cpufreq
the closest frequency to target.
Patch 2 is the actual change to ondemand governor.
You may find graphs with the 'deadband' effect and benchmark results:
https://docs.google.com/spreadsheets/d/16kDBh5lyc6YvBnoS1hUa1t2O38z0xrWvaEj5XtJ8auw/edit#gid=2072493052
Thanks
Stratos Karafotis (2
, running mp3 decoding (very low load) shows no differences with and
without this patch.
Signed-off-by: Stratos Karafotis strat...@semaphore.gr
---
drivers/cpufreq/cpufreq_ondemand.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_ondemand.c
b
Hi Doug,
On 12/07/2014 06:45 μμ, Doug Smythies wrote:
On 2014.07.30 10:00 Stratos Karafotis wrote:
This patchset changes slightly the calculation of target frequency to
eliminate the deadband effect (explained in patch 2 changelog) that it
seems to slow down the CPU in low and medium
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
On Mon, Sep 19, 2016 at 7:16 PM, Andreas Herrmann <aherrm...@suse.com> wrote:
> On Fri, Sep 16, 2016 at 09:58:42PM +0300, Stratos Karafotis wrote:
>> Hi,
>>
>> [ I 'm resending this message, because I think some recipients didn't receive
>> it. ]
>>
>
On 08/11/2016 10:32 πμ, Viresh Kumar wrote:
> On 8 November 2016 at 12:49, Stratos Karafotis <strat...@semaphore.gr> 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
after 0.86s
Signed-off-by: Stratos Karafotis <strat...@semaphore.gr>
---
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
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 freq
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:
>> Conservat
On 10/11/2016 02:13 πμ, Rafael J. Wysocki wrote:
> On Wed, Nov 9, 2016 at 6:55 AM, Viresh Kumar <viresh.ku...@linaro.org> wrote:
>> On 08-11-16, 21:25, Stratos Karafotis wrote:
>>> But this is the supposed behaviour of conservative governor. We want
>>> the CPU t
after 0.86s
Signed-off-by: Stratos Karafotis <strat...@semaphore.gr>
---
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
frequency after 0.86s
Signed-off-by: Stratos Karafotis <strat...@semaphore.gr>
---
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 +-
driver
The original comment about the frequency increase to maximum is wrong.
Both increase and decrease happen at steps.
Signed-off-by: Stratos Karafotis <strat...@semaphore.gr>
---
drivers/cpufreq/cpufreq_conservative.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/d
The original comment about the frequency increase to maximum is wrong.
Both increase and decrease happen at steps.
Signed-off-by: Stratos Karafotis <strat...@semaphore.gr>
---
-> v2
Remove a trailing space
drivers/cpufreq/cpufreq_conservative.c | 4 ++--
1 file changed, 2 inserti
frequency after 0.86s
Signed-off-by: Stratos Karafotis <strat...@semaphore.gr>
---
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' condit
frequency after 0.86s
Signed-off-by: Stratos Karafotis <strat...@semaphore.gr>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
---
v3 -> v4
- Fix format issues
- Ack by Viresh Kumar
v2 -> v3
- cpufreq_conservative.c: move the calculation below the block that check
the limits
- Calcu
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 <strat...@semaphore.gr>
---
drivers/cpufreq/cpufreq
On 14/11/2016 10:44 μμ, Rafael J. Wysocki wrote:
> On Sat, Nov 12, 2016 at 10:04 PM, Stratos Karafotis
> <strat...@semaphore.gr> wrote:
>> Conservative governor changes the CPU frequency in steps.
>> That means that if a CPU runs at max frequency, it will need sev
On 15/11/2016 12:09 πμ, Rafael J. Wysocki wrote:
> On Mon, Nov 14, 2016 at 10:59 PM, Rafael J. Wysocki <raf...@kernel.org> wrote:
>> On Mon, Nov 14, 2016 at 10:46 PM, Stratos Karafotis
>> <strat...@semaphore.gr> wrote:
>>>
>>>
>>> On 14/11/20
On 04/02/2013 04:50 PM, Rafael J. Wysocki wrote:
> Do you have any numbers indicating that this actually makes things better?
>
> Rafael
No, I don't.
The expected behaviour after this patch is to "force" max frequency few
sampling periods earlier.
The idea was to increase system responsiveness
On 04/03/2013 02:14 PM, Rafael J. Wysocki wrote:
> On Wednesday, April 03, 2013 12:13:56 PM Viresh Kumar wrote:
>> On 3 April 2013 12:01, stratosk wrote:
>>> I'm sorry, I don't understand.
>>> The goal of this patch is not energy saving.
>>
>> He probably misunderstood it...
>>
>>> The goal is to
-by: Stratos Karafotis
---
drivers/base/regmap/regcache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index d81f605..a469748 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -590,7
Hi Viresh,
On 04/04/2013 07:54 AM, Viresh Kumar wrote:
> Hi Stratos,
>
> Yes, your results show some improvements. BUT if performance is the only thing
> we were looking for, then we will never use ondemand governor but performance
> governor.
>
> I suspect this little increase in performance
On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
Hi Viresh,
On 04/04/2013 07:54 AM, Viresh Kumar wrote:
Hi Stratos,
Yes, your results show some improvements. BUT if performance is the only thing
we were looking for, then we will never use ondemand governor but performance
governor.
I suspect
’ was declared
here
Signed-off-by: Stratos Karafotis
---
drivers/md/dm-raid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index 1d3fe1a..8041de8 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -380,7 +380,7 @@ static int
On 08/18/2013 08:04 PM, Oleg Nesterov wrote:
> Sorry for double post. forgot to cc cpufreq maintainers.
>
> On 08/16, Frederic Weisbecker wrote:
>>
>> To fix this, lets only update the sleeptime stats locally when the CPU
>> exits from idle.
>
> I am in no position to ack the changes in this
On Fri, Nov 8, 2013 at 6:55 AM, Viresh Kumar wrote:
> On 8 November 2013 00:36, Stratos Karafotis wrote:
>> I think the existing code already checks if the requested_freq is greater
>> than policy->max in __cpufreq_driver_target.
>
> Yes it does. But the problem is:
On Fri, Nov 8, 2013 at 8:16 PM, Viresh Kumar wrote:
> On 8 November 2013 23:13, Stratos Karafotis wrote:
>> Please let me rephrase my previous post. In some circumstances (depending
>> on freq_step and freq_table values) CPU frequency will never reach to
>> policy->max.
&
After commit dfa5bb622555d9da0df21b50f46ebdeef390041b
"cpufreq: ondemand: Change the calculation of target frequency",
this return statement is no longer needed.
Reported-by: Henrik Nilsson
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_ondemand.c | 1 -
1 file
On 11/01/2013 02:18 AM, Rafael J. Wysocki wrote:
On Friday, November 01, 2013 12:09:16 AM Viresh Kumar wrote:
On 31 October 2013 23:57, Stratos Karafotis wrote:
After commit dfa5bb622555d9da0df21b50f46ebdeef390041b
"cpufreq: ondemand: Change the calculation of target frequency",
t
updated.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.h | 2 +-
drivers/cpufreq/cpufreq_ondemand.c | 16 ++--
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index
Fix some typos in comments.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_ondemand.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_ondemand.c
b/drivers/cpufreq/cpufreq_ondemand.c
index 09b27ae..f3eb26c 100644
Fix a couple of typos in comments.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_conservative.c
b/drivers/cpufreq/cpufreq_conservative.c
index e8bb915..4fd0006 100644
This patch restructures code for better readability and easier
maintenance.
Also introduces lowmemorykiller.h header file.
Signed-off-by: Stratos Karafotis
---
drivers/staging/android/lowmemorykiller.c | 162 ++
drivers/staging/android/lowmemorykiller.h | 42
On 02/01/2013 12:25 AM, Greg Kroah-Hartman wrote:
Given that no one is working on it, why does it need to be maintained
easier? :)
Thanks for your immediate response.
I was thinking to work on this driver. Is it going to be obsolete or
something?
Why create a .h file? Who needs it? Only
This patch fixes the following compiler warning of uninitialized
variable:
drivers/base/regmap/regmap-debugfs.c: In function ‘regmap_read_debugfs’:
drivers/base/regmap/regmap-debugfs.c:180:9: warning: ‘ret’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Stratos
. We use a parameter in
function get_cpu_idle_time to distinguish when the iowait time will be
added to idle time or not, without the need of keeping the prev_io_wait.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 2 +-
drivers/cpufreq/cpufreq_governor.c | 46
we re-calculate iowait time
and we subtract it from idle time.
With this patch iowait time is calculated only when necessary avoiding
the double call to get_cpu_iowait_time_us. We use a parameter in
function get_cpu_idle_time to distinguish when the iowait time will be
added to idle time or not,
On 04/10/2013 06:22 AM, Viresh Kumar wrote:
On 9 April 2013 22:26, Stratos Karafotis wrote:
On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
Hi Viresh,
On 04/04/2013 07:54 AM, Viresh Kumar wrote:
Hi Stratos,
Yes, your results show some improvements. BUT if performance is the only
thing
On 03/22/2013 01:54 AM, Rafael J. Wysocki wrote:
>
> Applied to linux-pm.git/bleeding-edge and will be moved to linux-next if there
> are no build problems in the bleeding-edge branch.
>
> Thanks,
> Rafael
Hi Rafael,
I just noticed a regression with this patch with the calculation of wall time
With commit 8755a8ae31ba213db196324011a0da2a85807f25 the wall in
get_cpu_idle_time is not calculated, when we use ondemand with
io_is_busy = 1, preventing the CPU to increase to max frequency.
Properly, calculate wall time when we use io_is_busy.
Signed-off-by: Stratos Karafotis
---
drivers
8<---
Use an inline function to evaluate freq_target to avoid duplicate code.
Also, define a macro for the default frequency step.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 28
1 file
Remove 3 sets of unnecessary braces
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 1eafd8c..ca3c01f 100644
--- a/drivers/cpufreq/cpufreq.c
Fix 2 checkpatch errors about using assignment in if condition,
1 checkpatch error about a required space after comma
and 3 warnings about line over 80 characters.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq.c | 23 ---
1 file changed, 12 insertions(+), 11
On 20/03/2014 12:45 πμ, Rafael J. Wysocki wrote:
> On Wednesday, March 19, 2014 11:33:00 PM Stratos Karafotis wrote:
>> Remove 3 sets of unnecessary braces
>>
>> Signed-off-by: Stratos Karafotis
>> ---
>> drivers/cpufreq/cpufreq.c | 11 ---
>> 1 fil
sampling_down_factor tunable is unused since commit
8e677ce83bf41ba9c74e5b6d9ee60b07d4e5ed93 (4 years ago).
This patch restores the original functionality.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Hi Viresh,
On 03/05/2013 02:23 AM, Viresh Kumar wrote:> Interesting. Because it was
removed earlier and no body complained :)
>
> I got following from Documentation:
>
> sampling_down_factor: this parameter controls the rate at which the
> kernel makes a decision on when to decrease the
On 03/05/2013 09:34 AM, Viresh Kumar wrote:
On 5 March 2013 13:22, Stratos Karafotis wrote:
I misread it here when i looked at this mail for the first time. :)
I strongly believe that we need a full stop (.) before "Every sampling_rate",
otherwise it looks like we check for down_fa
Hi David,
On 03/05/2013 04:21 PM, David C Niemi wrote:
I should clarify -- I wrote the sampling_down_factor in the *ondemand*
governor. I chose the name of the parameter based on the vaguely similar
parameter in the conservative governor, but the documentation that was
referenced (about it
sampling_down_factor tunable is unused since commit
8e677ce83bf41ba9c74e5b6d9ee60b07d4e5ed93 (4 years ago).
This patch restores the original functionality and documents the
tunable.
Signed-off-by: Stratos Karafotis
---
Documentation/cpu-freq/governors.txt | 6 ++
drivers/cpufreq
When we evaluate the CPU load for frequency decrease we have to compare
the load against down_threshold. There is no need to subtract 10 points
from down_threshold.
Instead, we have to use the default down_threshold or user's selection
unmodified.
Signed-off-by: Stratos Karafotis
---
drivers
Use an inline function to evaluate freq_target to avoid duplicate code.
Also, define a macro for the default frequency step and fix the
calculation of freq_target when the max freq is less that 100.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 27
for this confusion.
Below v2 of this patch.
Thanks,
Stratos
8<
Use an inline function to evaluate freq_target to avoid duplicate code.
Also, define a macro for the default frequency step.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.
On 03/06/2013 09:35 PM, David C Niemi wrote:
> The "10" sounds like an attempt to add some hysteresis to the up/down
> decisionmaking. If you take it out, you should make sure you don't get into
> situations where you're continually switching rapidly between two
> frequencies. (In the
Calculation of target frequency in ondemand governor changed and it is
independent from measured average frequency.
Remove unused__cpufreq_driver_getavg function and getavg member from
cpufreq_driver struct.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq.c | 12
Changes since v2:
- Reorder patches 2/3 and 3/3
- Fix typos in patch changelog
Changes since v1:
- Use policy->cpuinfo.max_freq in the calculation formula
of target frequency instead of policy->max
- Split the patch into 3 parts
Stratos Kar
Calculation of target frequency in ondemand governor changed and it is
independent from measured average frequency.
Remove unused APERF/MPERF support.
Signed-off-by: Stratos Karafotis
---
arch/x86/include/asm/processor.h | 29 ---
drivers/cpufreq/Makefile | 2
ies were used less by ~9%
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 10 +-
drivers/cpufreq/cpufreq_governor.h | 1 -
drivers/cpufreq/cpufreq_ondemand.c | 39 +++---
3 files changed, 8 insertions(+), 42 deletions(-)
diff --
Hi Borislav,
On 06/05/2013 07:17 PM, Borislav Petkov wrote:
On Wed, Jun 05, 2013 at 07:01:25PM +0300, Stratos Karafotis wrote:
Ondemand calculates load in terms of frequency and increases it only
if the load_freq is greater than up_threshold multiplied by current
or average frequency
Fix the following compiler warning:
fs/ext4/inode.c: In function ‘ext4_da_writepages’:
fs/ext4/inode.c:2212:6: warning: ‘err’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
fs/ext4/inode.c:2155:6: note: ‘err’ was declared here
Signed-off-by: Stratos Karafotis
---
fs/ext4
Hi Rafael,
I will try to provide the requested info (although, I'm not sure how to measure
total energy :) )
Thanks,
Stratos
"Rafael J. Wysocki" wrote:
>On Wednesday, June 05, 2013 08:13:26 PM Stratos Karafotis wrote:
>> Hi Borislav,
>>
>> On 06/05/2013
Thanks Viresh. I think I couldn't explain this in better way.
Also thanks for acknowledgment!
Stratos
Viresh Kumar wrote:
>On 6 June 2013 15:31, Borislav Petkov wrote:
>
>> Hold on, you say above "easily saturate minimum frequency and lead the
>> CPU to max". I read this as we jump straight
; of platforms/vendors if possible, please.
>
> Thanks.
>
On 06/06/2013 04:15 PM, Borislav Petkov wrote:> Please do not top-post.
>
> On Thu, Jun 06, 2013 at 03:54:20PM +0300, Stratos Karafotis wrote:
>> I will try to provide the requested info (although, I'm not sure how
>&g
On 06/06/2013 08:11 PM, Borislav Petkov wrote:
On Thu, Jun 06, 2013 at 07:46:17PM +0300, Stratos Karafotis wrote:
Apologies for top-posting. I was able to send email only from my phone.
Thanks for you hint about turbostat.
As you most probably understood, I'm individual amateur kernel
On 06/05/2013 11:35 PM, Rafael J. Wysocki wrote:
> On Wednesday, June 05, 2013 08:13:26 PM Stratos Karafotis wrote:
>> Hi Borislav,
>>
>> On 06/05/2013 07:17 PM, Borislav Petkov wrote:
>>> On Wed, Jun 05, 2013 at 07:01:25PM +0300, Stratos Karafotis wrote:
>>
On 06/07/2013 11:57 PM, Rafael J. Wysocki wrote:
> On Friday, June 07, 2013 10:14:34 PM Stratos Karafotis wrote:
>> On 06/05/2013 11:35 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, June 05, 2013 08:13:26 PM Stratos Karafotis wrote:
>>>> Hi Borislav,
>>>
consumption.
I will also send the results running the test as you said.
Thanks again,
Stratos
"Rafael J. Wysocki" wrote:
>On Saturday, June 08, 2013 12:56:00 PM Stratos Karafotis wrote:
>> On 06/07/2013 11:57 PM, Rafael J. Wysocki wrote:
>> > On Friday, June
On 06/08/2013 05:05 PM, Rafael J. Wysocki wrote:
> On Saturday, June 08, 2013 03:34:29 PM Stratos Karafotis wrote:
>> I also did the test with the way you mentioned. But I thought to run
>> turbostat for 100 sec as I did with powertop.
>
> Ah, OK.
>
>> Actually
On 06/09/2013 07:26 PM, Borislav Petkov wrote:
> On Sun, Jun 09, 2013 at 12:18:09AM +0200, Rafael J. Wysocki wrote:
>> The average power drawn by the package is slightly higher with the
>> patchset applied (27.66 W vs 27.25 W), but since the time needed to
>> complete the workload with the
are
attached with and without this patch. cpufreq_stats (time_in_state) are
also included. Tested on Intel i7-3770 CPU @ 3.40GH and on
Quad core 1500 MHz Krait.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 10 +-
drivers/cpufreq/cpufreq_governor.h | 1 -
drivers
ix benchmark of Linux Kernel Compilation 3.1 test shows an
increase 1.5% to performance. cpufreq_stats (time_in_state) shows
that middle frequencies are used more, with this patch. Highest
and lowest frequencies were used less by ~9%
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cp
On 05/28/2013 11:54 PM, Rafael J. Wysocki wrote:
> On Tuesday, May 28, 2013 08:03:19 PM Stratos Karafotis wrote:
>> I mean any value of freq table. Please let me know if you want me to rephrase
>> it in description.
>
> Yes, it would be nice to be more precise.
OK sure, I wi
On 05/30/2013 01:29 AM, Rafael J. Wysocki wrote:
On Wednesday, May 29, 2013 06:15:56 PM Stratos Karafotis wrote:
On 05/28/2013 11:54 PM, Rafael J. Wysocki wrote:
On Tuesday, May 28, 2013 08:03:19 PM Stratos Karafotis wrote:
I mean any value of freq table. Please let me know if you want me
used less by ~9%
Signed-off-by: Stratos Karafotis
---
arch/x86/include/asm/processor.h | 29 --
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/acpi-cpufreq.c | 5
drivers/cpufreq/cpufreq.c | 21
drivers/cpufreq
On 05/31/2013 11:51 AM, Viresh Kumar wrote:
>> ---
>> arch/x86/include/asm/processor.h | 29 --
>> drivers/cpufreq/Makefile | 2 +-
>> drivers/cpufreq/acpi-cpufreq.c | 5
>> drivers/cpufreq/cpufreq.c | 21
>>
On 06/01/2013 03:27 PM, Rafael J. Wysocki wrote:
> On Friday, May 31, 2013 07:33:06 PM Stratos Karafotis wrote:
>> On 05/31/2013 11:51 AM, Viresh Kumar wrote:
>>>> ---
>>>>arch/x86/include/asm/processor.h | 29 --
>>>&g
On 06/01/2013 05:56 PM, Viresh Kumar wrote:
> On 31 May 2013 22:03, Stratos Karafotis wrote:
>> On 05/31/2013 11:51 AM, Viresh Kumar wrote:
>>> I believe you should have removed other users of getavg() in a separate
>>> patch and also cc'd relevant people so that y
On 06/03/2013 02:24 PM, Viresh Kumar wrote:
> On 3 June 2013 16:27, Rafael J. Wysocki wrote:
>> The question is if we want policy->max to re-scale them effectively (i.e. to
>> change weights so that the maximum load maps to the highest frequency
>> available
>> at the moment) or if we want
ies were used less by ~9%
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 10 +-
drivers/cpufreq/cpufreq_governor.h | 1 -
drivers/cpufreq/cpufreq_ondemand.c | 39 +++---
3 files changed, 8 insertions(+), 42 deletions(-)
diff --
Changes since v1:
Use policy->cpuinfo.max_freq in the calculation formula
of target frequency instead of policy->max
Split the patch into 3 parts
Stratos Karafotis (3):
cpufreq: ondemand: Change the calculation of target frequency
cpufreq: Remove
Calculation of frequency target in ondemand governor changed and it is
independent from measured average frequency.
Remove unused__cpufreq_driver_getavg function and getavg member from
cpufreq_driver struct. Also, remove the callback getavg in
acpi_cpufreq_driver.
Signed-off-by: Stratos
Calculation of frequency target in ondemand governor changed and it is
independent from measured average frequency.
Remove unused APERF/MPERF support.
Signed-off-by: Stratos Karafotis
---
arch/x86/include/asm/processor.h | 29 ---
drivers/cpufreq/mperf.c | 51
On 06/04/2013 08:19 AM, Viresh Kumar wrote:
On 4 June 2013 01:18, Stratos Karafotis wrote:
Calculation of frequency target in ondemand governor changed and it is
s/frequency target/target frequency
I will change it also in 3/3 that I use the same.
independent from measured average
On 06/03/2013 11:38 PM, David C Niemi wrote:
>
> Interesting analysis; I just got back from vacation and have not had a chance
> to comment until now.
>
> I like Stratos' general idea of making the decision to upshift or downshift
> independent of current frequency, as it makes thinks simpler
I think you are right. I will reorder 2/3 and 3/3 with the change you suggested.
Thanks,
Stratos
Viresh Kumar wrote:
>On 4 June 2013 20:36, Stratos Karafotis wrote:
>> On 06/04/2013 08:19 AM, Viresh Kumar wrote:
>>> Should this be done in 3/3 ?
>>>
>>
>>
: controls the final up_threshold
- grad_up_threshold: over this gradient of load we will decrease
up_threshold by early_differential.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 1 +
drivers/cpufreq/cpufreq_governor.h | 4
drivers/cpufreq
e gradient of load_freq. If it is
too steep we assume that the load most probably will go over
up_threshold in next iteration(s) and we increase frequency immediately.
New tuners are introduced:
- early_demand: to enable this functionality (disabled by default).
- grad_up_threshold: over this gradient
steep we assume that the load most probably will go over
up_threshold in next iteration(s) and we increase frequency immediately.
New tuners are introduced:
- early_demand: to enable this functionality (disabled by default).
- grad_up_threshold: over this gradient of load we will increase
frequ
> On 6 March 2013 22:15, Stratos Karafotis wrote:
>> Use an inline function to evaluate freq_target to avoid duplicate code.
>>
>> Also, define a macro for the default frequency step.
>>
>> Signed-off-by: Stratos Karafotis
>> ---
>>
On 04/09/2013 07:56 PM, Stratos Karafotis wrote:
On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
Hi Viresh,
On 04/04/2013 07:54 AM, Viresh Kumar wrote:
Hi Stratos,
Yes, your results show some improvements. BUT if performance is the
only thing
we were looking for, then we will never use
Fix the following compiler warning (also a checkpatch error):
net/ipv6/xfrm6_mode_tunnel.c: In function ‘xfrm6_mode_tunnel_input’:
net/ipv6/xfrm6_mode_tunnel.c:72:2: warning: suggest parentheses around
assignment used as truth value [-Wparentheses]
Signed-off-by: Stratos Karafotis
---
net/ipv6
On 02/22/2013 03:56 AM, Viresh Kumar wrote:
> On 21 February 2013 23:09, Stratos Karafotis wrote:
>
>> Signed-off-by: Stratos Karafotis
>
> Acked-by: Viresh Kumar
>
Hi Rafael,
In case you are interested in this patch I rebased it to the latest
linux-pm/bleeding-e
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_pstate.c | 208
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:
>>&
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 be
`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/cpufreq/cpufreq.c | 11
201 - 300 of 446 matches
Mail list logo
