diff options
author | Joel Fernandes (Google) <joel@joelfernandes.org> | 2018-05-22 15:55:53 -0700 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2018-05-23 10:37:56 +0200 |
commit | 152db033d77589df9ff1b93c1b311d4cd2e93bd0 (patch) | |
tree | e8a93de140011a50752e7311973abe74f137913a /crypto/cfb.c | |
parent | 036399782bf51dafb932b680b260936b2b5f8dd6 (diff) | |
download | linux-stable-152db033d77589df9ff1b93c1b311d4cd2e93bd0.tar.gz linux-stable-152db033d77589df9ff1b93c1b311d4cd2e93bd0.tar.bz2 linux-stable-152db033d77589df9ff1b93c1b311d4cd2e93bd0.zip |
schedutil: Allow cpufreq requests to be made even when kthread kicked
Currently there is a chance of a schedutil cpufreq update request to be
dropped if there is a pending update request. This pending request can
be delayed if there is a scheduling delay of the irq_work and the wake
up of the schedutil governor kthread.
A very bad scenario is when a schedutil request was already just made,
such as to reduce the CPU frequency, then a newer request to increase
CPU frequency (even sched deadline urgent frequency increase requests)
can be dropped, even though the rate limits suggest that its Ok to
process a request. This is because of the way the work_in_progress flag
is used.
This patch improves the situation by allowing new requests to happen
even though the old one is still being processed. Note that in this
approach, if an irq_work was already issued, we just update next_freq
and don't bother to queue another request so there's no extra work being
done to make this happen.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'crypto/cfb.c')
0 files changed, 0 insertions, 0 deletions