lkml.org 
[lkml]   [2013]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] cpufreq: conservative: fix requested_freq reduction issue
From
On 8 November 2013 23:13, Stratos Karafotis <skarafotis@gmail.com> 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.
>
> For example suppose that (for simplicity values in MHz):
> policy->max = 1000
> policy->cur = 800
> requested_freq = 800
> freq_target = 300
>
> In 'first' iteration, if we return early with this code (because
> requested_freq will be
> 1100):
> if (dbs_info->requested_freq >= policy->max)
> return;

That's not correct. At this point requested_freq would have been
800 only, and would have increased after this instruction to 1100.
So, in the first transition we will go to max freq, but not from the
second.

Though this piece of code is more simplified by the new solution
I gave.

> CPU freq will never go over 800MHz.
>
> I think the current code works correctly.
> - The requested freq will go to 1100 in first iteration.
> - __cpufreq_driver_target will change CPU freq to 1000
> - dbs_cpufreq_notifier will adjust the requested_freq to 1000

> So, I think there is no need for an extra check because of
> dbs_cpufreq_notifier code.

Now with the new code in place we are correcting requested_freq
in cs_check_cpu(), then why do we need dbs_cpufreq_notifier()?

What do you think?


\
 
 \ /
  Last update: 2013-11-08 19:41    [W:0.081 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site