cpufreq: schedutil: Don't set next_freq to UINT_MAX
authorViresh Kumar <viresh.kumar@linaro.org>
Wed, 9 May 2018 10:35:24 +0000 (16:05 +0530)
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tue, 15 May 2018 08:38:12 +0000 (10:38 +0200)
commitecd2884291261e3fddbc7651ee11a20d596bb514
tree8fd4252e61cce2b673b4613de9fe3cf6e716c6ce
parent1b04722c3b892033f143d056a2876f293a1adbcc
cpufreq: schedutil: Don't set next_freq to UINT_MAX

The schedutil driver sets sg_policy->next_freq to UINT_MAX on certain
occasions to discard the cached value of next freq:
- In sugov_start(), when the schedutil governor is started for a group
  of CPUs.
- And whenever we need to force a freq update before rate-limit
  duration, which happens when:
  - there is an update in cpufreq policy limits.
  - Or when the utilization of DL scheduling class increases.

In return, get_next_freq() doesn't return a cached next_freq value but
recalculates the next frequency instead.

But having special meaning for a particular value of frequency makes the
code less readable and error prone. We recently fixed a bug where the
UINT_MAX value was considered as valid frequency in
sugov_update_single().

All we need is a flag which can be used to discard the value of
sg_policy->next_freq and we already have need_freq_update for that. Lets
reuse it instead of setting next_freq to UINT_MAX.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
kernel/sched/cpufreq_schedutil.c