lkml.org 
[lkml]   [2011]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
Subject[PATCH v0] sched: change how RT task is picked in pull_rt_task()
From
When pulling RT task for a given run-queue, the method to pick RT task
is changed from pick_next_highest_task_rt() to
pick_next_pushable_task(). Though job could be done with both, the
former could be replaced since plist_first_entry() is simpler and
faster.
Based on the simplicity, then the racy before and WARN_ON after
run-queue lock could be removed.

Signed-off-by: Hillf Danton <dhillf@gmail.com>
---

--- a/kernel/sched_rt.c 2011-04-27 11:48:50.000000000 +0800
+++ b/kernel/sched_rt.c 2011-05-21 00:34:18.000000000 +0800
@@ -1434,64 +1434,19 @@ static int pull_rt_task(struct rq *this_
continue;

src_rq = cpu_rq(cpu);
-
- /*
- * Don't bother taking the src_rq->lock if the next highest
- * task is known to be lower-priority than our current task.
- * This may look racy, but if this value is about to go
- * logically higher, the src_rq will push this task away.
- * And if its going logically lower, we do not care
- */
- if (src_rq->rt.highest_prio.next >=
- this_rq->rt.highest_prio.curr)
- continue;
-
- /*
- * We can potentially drop this_rq's lock in
- * double_lock_balance, and another CPU could
- * alter this_rq
- */
double_lock_balance(this_rq, src_rq);

- /*
- * Are there still pullable RT tasks?
- */
- if (src_rq->rt.rt_nr_running <= 1)
+ p = pick_next_pushable_task(src_rq);
+ if (!p ||
+ !cpumask_test_cpu(this_cpu, &p->cpus_allowed) ||
+ !(p->prio < this_rq->rt.highest_prio.curr))
goto skip;

- p = pick_next_highest_task_rt(src_rq, this_cpu);
+ ret++;
+ deactivate_task(src_rq, p, 0);
+ set_task_cpu(p, this_cpu);
+ activate_task(this_rq, p, 0);

- /*
- * Do we have an RT task that preempts
- * the to-be-scheduled task?
- */
- if (p && (p->prio < this_rq->rt.highest_prio.curr)) {
- WARN_ON(p == src_rq->curr);
- WARN_ON(!p->se.on_rq);
-
- /*
- * There's a chance that p is higher in priority
- * than what's currently running on its cpu.
- * This is just that p is wakeing up and hasn't
- * had a chance to schedule. We only pull
- * p if it is lower in priority than the
- * current task on the run queue
- */
- if (p->prio < src_rq->curr->prio)
- goto skip;
-
- ret = 1;
-
- deactivate_task(src_rq, p, 0);
- set_task_cpu(p, this_cpu);
- activate_task(this_rq, p, 0);
- /*
- * We continue with the search, just in
- * case there's an even higher prio task
- * in another runqueue. (low likelihood
- * but possible)
- */
- }
skip:
double_unlock_balance(this_rq, src_rq);
}

\
 
 \ /
  Last update: 2011-05-20 18:47    [W:0.036 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site