aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/util/trace-event-scripting.c
diff options
context:
space:
mode:
authorVincent Guittot <[email protected]>2018-06-26 15:53:22 +0200
committerIngo Molnar <[email protected]>2018-07-03 09:17:28 +0200
commit296b2ffe7fa9ed756c41415c6b1512bc4ad687b1 (patch)
tree11267161f1a90159ac9a47dcf48dbadfd44ef9cc /tools/perf/util/trace-event-scripting.c
parentd9c0ffcabd6aae7ff1e34e8078354c13bb9f1183 (diff)
sched/rt: Fix call to cpufreq_update_util()
With commit: 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") the schedutil governor uses rq->rt.rt_nr_running to detect whether an RT task is currently running on the CPU and to set frequency to max if necessary. cpufreq_update_util() is called in enqueue/dequeue_top_rt_rq() but rq->rt.rt_nr_running has not been updated yet when dequeue_top_rt_rq() is called so schedutil still considers that an RT task is running when the last task is dequeued. The update of rq->rt.rt_nr_running happens later in dequeue_rt_stack(). In fact, we can take advantage of the sequence that the dequeue then re-enqueue rt entities when a rt task is enqueued or dequeued; As a result enqueue_top_rt_rq() is always called when a task is enqueued or dequeued and also when groups are throttled or unthrottled. The only place that not use enqueue_top_rt_rq() is when root rt_rq is throttled. Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Fixes: 8f111bc357aa ('cpufreq/schedutil: Rewrite CPUFREQ_RT support') Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
Diffstat (limited to 'tools/perf/util/trace-event-scripting.c')
0 files changed, 0 insertions, 0 deletions