From: Patrick Bellasi <patrick.bellasi@arm.com>
To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Cc: Patrick Bellasi <patrick.bellasi@arm.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Steven Rostedt <rostedt@goodmis.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
John Stultz <john.stultz@linaro.org>,
Juri Lelli <juri.lelli@arm.com>, Todd Kjos <tkjos@android.com>,
Tim Murray <timmurray@google.com>,
Andres Oportus <andresoportus@google.com>,
Joel Fernandes <joelaf@google.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Chris Redpath <chris.redpath@arm.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>
Subject: [PATCH 6/6] sched/rt: fast switch to maximum frequency when RT tasks are scheduled
Date: Thu, 2 Mar 2017 15:45:07 +0000 [thread overview]
Message-ID: <1488469507-32463-7-git-send-email-patrick.bellasi@arm.com> (raw)
In-Reply-To: <1488469507-32463-1-git-send-email-patrick.bellasi@arm.com>
Currently schedutil updates are triggered for the RT class using a single
call place, which is part of the rt::update_curr_rt() used in:
- dequeue_task_rt:
but it does not make sense to set the schedutil's SCHED_CPUFREQ_RT in
case the next task should not be an RT one
- put_prev_task_rt:
likewise, we set the SCHED_CPUFREQ_RT flag without knowing if required
by the next task
- pick_next_task_rt:
likewise, the schedutil's SCHED_CPUFREQ_RT is set in case the prev task
was RT, while we don't yet know if the next will be RT
- task_tick_rt:
that's the only really useful call, which can ramp up the frequency in
case a RT task started its execution without a chance to order a
frequency switch (e.g. because of the schedutil ratelimit)
Apart from the last call in task_tick_rt, the others are at least useless.
Thus, although being a simple solution, not all the call sites of that
update_curr_rt() are interesting to trigger a frequency switch as well as
some of the most interesting points are not covered by that call.
For example, a task set to RT has to wait the next tick to get the frequency
boost.
This patch fixes these issue by placing explicitly the schedutils update
calls in the only sensible places, which are:
- when an RT task wakeups and it's enqueued in a CPU
- when we actually pick a RT task for execution
- at each tick time
- when a task is set to be RT
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
---
kernel/sched/rt.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 4101f9d..df7046c 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -958,9 +958,6 @@ static void update_curr_rt(struct rq *rq)
if (unlikely((s64)delta_exec <= 0))
return;
- /* Kick cpufreq (see the comment in kernel/sched/sched.h). */
- cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT);
-
schedstat_set(curr->se.statistics.exec_max,
max(curr->se.statistics.exec_max, delta_exec));
@@ -1326,6 +1323,9 @@ enqueue_task_rt(struct rq *rq, struct task_struct *p, int flags)
if (!task_current(rq, p) && tsk_nr_cpus_allowed(p) > 1)
enqueue_pushable_task(rq, p);
+
+ /* Kick cpufreq (see the comment in kernel/sched/sched.h). */
+ cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT);
}
static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)
@@ -1563,6 +1563,9 @@ pick_next_task_rt(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
p = _pick_next_task_rt(rq);
+ /* Kick cpufreq (see the comment in kernel/sched/sched.h). */
+ cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT);
+
/* The running task is never eligible for pushing */
dequeue_pushable_task(rq, p);
@@ -2272,6 +2275,9 @@ static void task_tick_rt(struct rq *rq, struct task_struct *p, int queued)
{
struct sched_rt_entity *rt_se = &p->rt;
+ /* Kick cpufreq (see the comment in kernel/sched/sched.h). */
+ cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT);
+
update_curr_rt(rq);
watchdog(rq, p);
@@ -2307,6 +2313,9 @@ static void set_curr_task_rt(struct rq *rq)
p->se.exec_start = rq_clock_task(rq);
+ /* Kick cpufreq (see the comment in kernel/sched/sched.h). */
+ cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT);
+
/* The running task is never eligible for pushing */
dequeue_pushable_task(rq, p);
}
--
2.7.4
next prev parent reply other threads:[~2017-03-02 15:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-02 15:45 [PATCH 0/6] cpufreq: schedutil: fixes for flags updates Patrick Bellasi
2017-03-02 15:45 ` [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter Patrick Bellasi
2017-03-03 3:41 ` Viresh Kumar
2017-03-06 14:29 ` Steven Rostedt
2017-03-15 18:06 ` Patrick Bellasi
2017-03-28 22:18 ` Rafael J. Wysocki
2017-04-07 14:59 ` Patrick Bellasi
2017-06-06 9:26 ` Viresh Kumar
2017-06-06 15:56 ` Rafael J. Wysocki
2017-06-06 18:03 ` Patrick Bellasi
2017-03-02 15:45 ` [PATCH 2/6] cpufreq: schedutil: ignore the sugov kthread for frequencies selections Patrick Bellasi
2017-03-03 5:19 ` Viresh Kumar
2017-03-03 12:12 ` Patrick Bellasi
2017-03-06 5:08 ` Viresh Kumar
2017-03-06 14:35 ` Steven Rostedt
2017-03-15 18:02 ` Patrick Bellasi
2017-03-02 15:45 ` [PATCH 3/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks Patrick Bellasi
2017-03-03 8:31 ` Viresh Kumar
2017-03-03 12:38 ` Patrick Bellasi
2017-03-15 11:52 ` Rafael J. Wysocki
2017-03-15 14:40 ` Patrick Bellasi
2017-03-15 23:32 ` Rafael J. Wysocki
2017-03-17 11:36 ` Patrick Bellasi
2017-04-07 15:30 ` Peter Zijlstra
2017-04-07 16:59 ` Patrick Bellasi
2017-03-02 15:45 ` [PATCH 4/6] cpufreq: schedutil: relax rate-limiting " Patrick Bellasi
2017-03-02 15:45 ` [PATCH 5/6] cpufreq: schedutil: avoid utilisation update when not necessary Patrick Bellasi
2017-03-02 15:45 ` Patrick Bellasi [this message]
2017-03-02 16:09 ` [PATCH 0/6] cpufreq: schedutil: fixes for flags updates Vincent Guittot
2017-03-02 17:11 ` Patrick Bellasi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1488469507-32463-7-git-send-email-patrick.bellasi@arm.com \
--to=patrick.bellasi@arm.com \
--cc=andresoportus@google.com \
--cc=chris.redpath@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=john.stultz@linaro.org \
--cc=juri.lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rostedt@goodmis.org \
--cc=timmurray@google.com \
--cc=tkjos@android.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).