summaryrefslogtreecommitdiffstats
path: root/crypto/cfb.c
diff options
context:
space:
mode:
authorJoel Fernandes (Google) <joel@joelfernandes.org>2018-05-22 15:55:53 -0700
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2018-05-23 10:37:56 +0200
commit152db033d77589df9ff1b93c1b311d4cd2e93bd0 (patch)
treee8a93de140011a50752e7311973abe74f137913a /crypto/cfb.c
parent036399782bf51dafb932b680b260936b2b5f8dd6 (diff)
downloadlinux-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