Re: [PATCH] cpufreq: conservative: fix requested_freq reduction issue

[Viresh Kumar]

On 8 November 2013 23:13, Stratos Karafotis <skarafotis@xxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/