Re: [PATCH 2/3 linux-next] cpufreq: conservative: Fix the logic in frequency decrease checking

2013-03-06 Thread Stratos Karafotis
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

Re: [PATCH 2/3 linux-next] cpufreq: conservative: Fix the logic in frequency decrease checking

2013-03-06 Thread David C Niemi
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 ondemand governor some care was also taken to avoid the cost

Re: [PATCH 2/3 linux-next] cpufreq: conservative: Fix the logic in frequency decrease checking

2013-03-06 Thread David C Niemi
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 ondemand governor some care was also taken to avoid the cost

Re: [PATCH 2/3 linux-next] cpufreq: conservative: Fix the logic in frequency decrease checking

2013-03-06 Thread Stratos Karafotis
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 ondemand

Re: [PATCH 2/3 linux-next] cpufreq: conservative: Fix the logic in frequency decrease checking

2013-03-05 Thread Viresh Kumar
On 6 March 2013 06:06, Stratos Karafotis wrote: > 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 >

[PATCH 2/3 linux-next] cpufreq: conservative: Fix the logic in frequency decrease checking

2013-03-05 Thread Stratos Karafotis
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 ---

[PATCH 2/3 linux-next] cpufreq: conservative: Fix the logic in frequency decrease checking

2013-03-05 Thread Stratos Karafotis
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

Re: [PATCH 2/3 linux-next] cpufreq: conservative: Fix the logic in frequency decrease checking

2013-03-05 Thread Viresh Kumar
On 6 March 2013 06:06, Stratos Karafotis strat...@semaphore.gr wrote: 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