From: Tim Chen <tim.c.chen@linux.intel.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>, Andi Kleen <andi@firstfloor.org>,
Shawn Bohrer <sbohrer@rgmadvisors.com>,
Suruchi Kadu <suruchi.a.kadu@intel.com>,
Doug Nelson <doug.nelson@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Repost sched-rt: Reduce rq lock contention by eliminating locking of non-feasible target
Date: Fri, 16 Jan 2015 09:46:14 -0800 [thread overview]
Message-ID: <1421430374.2399.27.camel@schen9-desk2.jf.intel.com> (raw)
In-Reply-To: <20150115205837.22075a58@grimm.local.home>
On Thu, 2015-01-15 at 20:58 -0500, Steven Rostedt wrote:
>
> Please add a comment here that says something like:
>
> /*
> * Don't bother moving it if the destination CPU is
> * not running a lower priority task.
> */
>
Okay. Updated in patch below.
> > - if (target != -1)
> > + if (target != -1 &&
> > + p->prio < cpu_rq(target)->rt.highest_prio.curr)
> > cpu = target;
> > }
> > rcu_read_unlock();
> > @@ -1613,6 +1614,12 @@ static struct rq *find_lock_lowest_rq(struct
> > task_struct *task, struct rq *rq) break;
> >
> > lowest_rq = cpu_rq(cpu);
> > +
> > + if (lowest_rq->rt.highest_prio.curr <= task->prio) {
> > + /* target rq has tasks of equal or higher priority,
> > try again */
> > + lowest_rq = NULL;
> > + continue;
>
> This should just break out and not try again. The reason for the other
> try again is because of the double_lock which can release the locks
> which can cause a process waiting for the lock to sneak in and
> change the priorities. But this case, a try again is highly unlikely to
> do anything differently (no locks are released) and just waste cycles.
Agree. Updated in updated patch below.
Thanks.
Tim
---->8------
>From 5f676f7a351e85eb5cc64f1971dd03eca43b5271 Mon Sep 17 00:00:00 2001
From: Tim Chen <tim.c.chen@linux.intel.com>
Date: Fri, 12 Dec 2014 15:38:12 -0800
Subject: [PATCH] sched-rt: Reduce rq lock contention by eliminating
locking of
non-feasible target
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@elte.hu>,
Shawn Bohrer <sbohrer@rgmadvisors.com>, Steven Rostedt
<rostedt@goodmis.org>, Suruchi Kadu <suruchi.a.kadu@intel.com>, Doug
Nelson <doug.nelson@intel.com>, linux-kernel@vger.kernel.org
This patch added checks that prevent futile attempts to move rt tasks
to cpu with active tasks of equal or higher priority. This reduces
run queue lock contention and improves the performance of a well
known OLTP benchmark by 0.7%.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
---
kernel/sched/rt.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index ee15f5a..46ebcb1 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1337,7 +1337,12 @@ select_task_rq_rt(struct task_struct *p, int cpu, int sd_flag, int flags)
curr->prio <= p->prio)) {
int target = find_lowest_rq(p);
- if (target != -1)
+ /*
+ * Don't bother moving it if the destination CPU is
+ * not running a lower priority task.
+ */
+ if (target != -1 &&
+ p->prio < cpu_rq(target)->rt.highest_prio.curr)
cpu = target;
}
rcu_read_unlock();
@@ -1614,6 +1619,16 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq)
lowest_rq = cpu_rq(cpu);
+ if (lowest_rq->rt.highest_prio.curr <= task->prio) {
+ /*
+ * Target rq has tasks of equal or higher priority,
+ * retrying does not release any lock and is unlikely
+ * to yield a different result.
+ */
+ lowest_rq = NULL;
+ break;
+ }
+
/* if the prio of this runqueue changed, try again */
if (double_lock_balance(rq, lowest_rq)) {
/*
--
1.8.3.1
next prev parent reply other threads:[~2015-01-16 17:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-06 19:01 Tim Chen
2015-01-06 19:30 ` Peter Zijlstra
2015-01-15 17:13 ` Tim Chen
2015-01-16 1:58 ` Steven Rostedt
2015-01-16 17:46 ` Tim Chen [this message]
2015-01-22 17:48 ` Tim Chen
2015-02-01 17:52 ` [tip:sched/core] sched/rt: " tip-bot for Tim Chen
2015-02-24 16:12 ` Steven Rostedt
2015-03-03 21:12 ` Ben Hutchings
2015-04-09 1:17 ` Zefan Li
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=1421430374.2399.27.camel@schen9-desk2.jf.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=doug.nelson@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sbohrer@rgmadvisors.com \
--cc=suruchi.a.kadu@intel.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
all inboxes | Powered by JetHome®