From: Xunlei Pang <xlpang@126.com>
To: linux-kernel@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Juri Lelli <juri.lelli@gmail.com>, Ingo Molnar <mingo@redhat.com>,
Xunlei Pang <pang.xunlei@linaro.org>
Subject: [RFC PATCH RESEND 1/4] sched/rt: Modify check_preempt_equal_prio() for multiple tasks queued at the same priority
Date: Mon, 27 Apr 2015 14:48:35 +0800 [thread overview]
Message-ID: <1430117318-2080-2-git-send-email-xlpang@126.com> (raw)
In-Reply-To: <1430117318-2080-1-git-send-email-xlpang@126.com>
From: Xunlei Pang <pang.xunlei@linaro.org>
In check_preempt_equal_prio(), when p is queued, there may be other
tasks already queued at the same priority in the "run queue", so we
should peek the most front one to do the preemption, not the p.
This patch modified it and moved the preemption job to a new function
named check_preempt_equal_prio_common() to make the logic clearer.
Signed-off-by: Xunlei Pang <pang.xunlei@linaro.org>
---
kernel/sched/rt.c | 70 ++++++++++++++++++++++++++++++++++++++++++-------------
1 file changed, 54 insertions(+), 16 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 575da76..0c0f4df 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1366,33 +1366,66 @@ out:
return cpu;
}
-static void check_preempt_equal_prio(struct rq *rq, struct task_struct *p)
+static struct task_struct *peek_next_task_rt(struct rq *rq);
+
+static void check_preempt_equal_prio_common(struct rq *rq)
{
+ struct task_struct *curr = rq->curr;
+ struct task_struct *next;
+
+ /* Current can't be migrated, useless to reschedule */
+ if (curr->nr_cpus_allowed == 1 ||
+ !cpupri_find(&rq->rd->cpupri, curr, NULL))
+ return;
+
/*
- * Current can't be migrated, useless to reschedule,
- * let's hope p can move out.
+ * Can we find any task with the same priority as
+ * curr? To accomplish this, firstly requeue curr
+ * to the tail, then peek next, finally put curr
+ * back to the head if a different task was peeked.
*/
- if (rq->curr->nr_cpus_allowed == 1 ||
- !cpupri_find(&rq->rd->cpupri, rq->curr, NULL))
+ requeue_task_rt(rq, curr, 0);
+ next = peek_next_task_rt(rq);
+ if (next == curr)
+ return;
+
+ requeue_task_rt(rq, curr, 1);
+
+ if (next->prio != curr->prio)
return;
/*
- * p is migratable, so let's not schedule it and
- * see if it is pushed or pulled somewhere else.
+ * Got the right "next" queued with the same priority
+ * as current. If next is migratable, don't schedule
+ * it as it will be pushed or pulled somewhere else.
*/
- if (p->nr_cpus_allowed != 1
- && cpupri_find(&rq->rd->cpupri, p, NULL))
+ if (next->nr_cpus_allowed != 1 &&
+ cpupri_find(&rq->rd->cpupri, next, NULL))
return;
/*
* There appears to be other cpus that can accept
- * current and none to run 'p', so lets reschedule
- * to try and push current away:
+ * current and none to run next, so lets reschedule
+ * to try and push current away.
*/
- requeue_task_rt(rq, p, 1);
+ requeue_task_rt(rq, next, 1);
resched_curr(rq);
}
+static inline
+void check_preempt_equal_prio(struct rq *rq, struct task_struct *p)
+{
+ /*
+ * p is migratable, so let's not schedule it and
+ * see if it is pushed or pulled somewhere else.
+ */
+ if (p->nr_cpus_allowed != 1 &&
+ cpupri_find(&rq->rd->cpupri, p, NULL))
+ return;
+
+ check_preempt_equal_prio_common(rq);
+}
+
#endif /* CONFIG_SMP */
/*
@@ -1440,10 +1473,9 @@ static struct sched_rt_entity *pick_next_rt_entity(struct rq *rq,
return next;
}
-static struct task_struct *_pick_next_task_rt(struct rq *rq)
+static struct task_struct *peek_next_task_rt(struct rq *rq)
{
struct sched_rt_entity *rt_se;
- struct task_struct *p;
struct rt_rq *rt_rq = &rq->rt;
do {
@@ -1452,9 +1484,15 @@ static struct task_struct *_pick_next_task_rt(struct rq *rq)
rt_rq = group_rt_rq(rt_se);
} while (rt_rq);
- p = rt_task_of(rt_se);
- p->se.exec_start = rq_clock_task(rq);
+ return rt_task_of(rt_se);
+}
+static inline struct task_struct *_pick_next_task_rt(struct rq *rq)
+{
+ struct task_struct *p;
+
+ p = peek_next_task_rt(rq);
+ p->se.exec_start = rq_clock_task(rq);
return p;
}
--
1.9.1
next prev parent reply other threads:[~2015-04-27 6:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-27 6:48 [RFC PATCH RESEND 0/4] Maintain the FIFO order for same priority RT tasks Xunlei Pang
2015-04-27 6:48 ` Xunlei Pang [this message]
2015-04-27 6:48 ` [RFC PATCH RESEND 2/4] lib/plist: Provide plist_add_head() for nodes with the same prio Xunlei Pang
2015-04-27 6:48 ` [RFC PATCH RESEND 3/4] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases Xunlei Pang
2015-04-27 6:48 ` [RFC PATCH RESEND 4/4] sched/rt: Requeue p back if the preemption initiated by check_preempt_equal_prio_common() failed Xunlei Pang
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=1430117318-2080-2-git-send-email-xlpang@126.com \
--to=xlpang@126.com \
--cc=juri.lelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pang.xunlei@linaro.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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
all inboxes | Powered by JetHome®