[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1429518168-7965-2-git-send-email-xlpang@126.com>
Date: Mon, 20 Apr 2015 16:22:47 +0800
From: Xunlei Pang <xlpang@....com>
To: linux-kernel@...r.kernel.org
Cc: Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Juri Lelli <juri.lelli@...il.com>,
Xunlei Pang <pang.xunlei@...aro.org>
Subject: [PATCH v6 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases
From: Xunlei Pang <pang.xunlei@...aro.org>
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away instead
of RT1 afterwards, because RT1 will be enqueued to the tail of
the pushable list when going through succeeding put_prev_task_rt()
triggered by resched. This broke FIFO.
Furthermore, this is also problematic for normal preempted cases
if there're some rt tasks queued with the same prio as current.
Because current will be put behind these tasks in the pushable
queue.
So, if a task is running and gets preempted by a higher priority
task (or even with same priority for migrating), this patch ensures
that it is put ahead of any existing task with the same priority in
the pushable queue.
Suggested-by: Steven Rostedt <rostedt@...dmis.org>
Signed-off-by: Xunlei Pang <pang.xunlei@...aro.org>
---
v5->v6:
Add wrapped enqueue_pushable_task_preempted() and enqueue_pushable_task()
for __enqueue_pushable_task() to avoid the "bool head" parameter everywhere.
kernel/sched/rt.c | 41 +++++++++++++++++++++++++++++++++++++----
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 575da76..8679eff 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -359,17 +359,32 @@ static inline void set_post_schedule(struct rq *rq)
rq->post_schedule = has_pushable_tasks(rq);
}
-static void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
+static void
+__enqueue_pushable_task(struct rq *rq, struct task_struct *p, bool head)
{
plist_del(&p->pushable_tasks, &rq->rt.pushable_tasks);
plist_node_init(&p->pushable_tasks, p->prio);
- plist_add(&p->pushable_tasks, &rq->rt.pushable_tasks);
+ if (head)
+ plist_add_head(&p->pushable_tasks, &rq->rt.pushable_tasks);
+ else
+ plist_add_tail(&p->pushable_tasks, &rq->rt.pushable_tasks);
/* Update the highest prio pushable task */
if (p->prio < rq->rt.highest_prio.next)
rq->rt.highest_prio.next = p->prio;
}
+static inline
+void enqueue_pushable_task_preempted(struct rq *rq, struct task_struct *p)
+{
+ __enqueue_pushable_task(rq, p, true);
+}
+
+static inline void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
+{
+ __enqueue_pushable_task(rq, p, false);
+}
+
static void dequeue_pushable_task(struct rq *rq, struct task_struct *p)
{
plist_del(&p->pushable_tasks, &rq->rt.pushable_tasks);
@@ -385,6 +400,11 @@ static void dequeue_pushable_task(struct rq *rq, struct task_struct *p)
#else
+static inline
+void enqueue_pushable_task_preempted(struct rq *rq, struct task_struct *p)
+{
+}
+
static inline void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
{
}
@@ -1506,8 +1526,21 @@ static void put_prev_task_rt(struct rq *rq, struct task_struct *p)
* The previous task needs to be made eligible for pushing
* if it is still active
*/
- if (on_rt_rq(&p->rt) && p->nr_cpus_allowed > 1)
- enqueue_pushable_task(rq, p);
+ if (on_rt_rq(&p->rt) && p->nr_cpus_allowed > 1) {
+ /*
+ * put_prev_task_rt() is called by many functions,
+ * pick_next_task_rt() is the only one may have
+ * PREEMPT_ACTIVE set. So if detecting p(current
+ * task) is preempted in such case, we should
+ * enqueue it to the front of the pushable plist,
+ * as there may be multiple tasks with the same
+ * priority as p.
+ */
+ if (preempt_count() & PREEMPT_ACTIVE)
+ enqueue_pushable_task_preempted(rq, p);
+ else
+ enqueue_pushable_task(rq, p);
+ }
}
#ifdef CONFIG_SMP
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists