From: Steven Rostedt <rostedt@goodmis.org>
To: Shawn Bohrer <sbohrer@rgmadvisors.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched_rt: Migrate equal priority tasks to available CPUs
Date: Tue, 13 Sep 2011 09:05:46 -0400 [thread overview]
Message-ID: <1315919147.26295.1.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <1315837684-18733-1-git-send-email-sbohrer@rgmadvisors.com>
On Mon, 2011-09-12 at 09:28 -0500, Shawn Bohrer wrote:
> Commit 43fa5460fe60dea5c610490a1d263415419c60f6 "sched: Try not to
> migrate higher priority RT tasks" also introduced a change in behavior
> which keeps RT tasks on the same CPU if there is an equal priority RT
> task currently running even if there are empty CPUs available. This can
> cause unnecessary wakeup latencies, and can prevent the scheduler from
> balancing all RT tasks across the available CPUs.
>
> This change causes an RT task to search for a new CPU if an equal
> priority RT task is already running on wakeup. Lower priority tasks
> will still have to wait on higher priority tasks, but the system should
> still balance out because there is always the possibility that if there
> are both a high and low priority RT tasks on a given CPU that the high
> priority task could wakeup while the low priority task is running and
> force it to search for a better runqueue.
>
Looks good, but do you have a test case that shows the issue? I like to
have something that proves even the obvious before making changes to the
schedule.
If not, I probably could write a test case to trigger this.
Thanks!
-- Steve
> Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
> ---
> kernel/sched_rt.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
> index 10d0182..17f2319 100644
> --- a/kernel/sched_rt.c
> +++ b/kernel/sched_rt.c
> @@ -1038,7 +1038,7 @@ select_task_rq_rt(struct task_struct *p, int sd_flag, int flags)
> */
> if (curr && unlikely(rt_task(curr)) &&
> (curr->rt.nr_cpus_allowed < 2 ||
> - curr->prio < p->prio) &&
> + curr->prio <= p->prio) &&
> (p->rt.nr_cpus_allowed > 1)) {
> int target = find_lowest_rq(p);
>
> @@ -1569,7 +1569,7 @@ static void task_woken_rt(struct rq *rq, struct task_struct *p)
> p->rt.nr_cpus_allowed > 1 &&
> rt_task(rq->curr) &&
> (rq->curr->rt.nr_cpus_allowed < 2 ||
> - rq->curr->prio < p->prio))
> + rq->curr->prio <= p->prio))
> push_rt_tasks(rq);
> }
>
next prev parent reply other threads:[~2011-09-13 13:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-12 14:28 [PATCH] sched_rt: Migrate equal priority tasks to available CPUs Shawn Bohrer
2011-09-13 13:05 ` Steven Rostedt [this message]
2011-09-13 16:27 ` Shawn Bohrer
2011-09-13 20:06 ` Shawn Bohrer
2011-09-13 20:51 ` Steven Rostedt
2011-09-14 15:27 ` Peter Zijlstra
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=1315919147.26295.1.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=sbohrer@rgmadvisors.com \
/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