linux-kernel - [PATCH v0] sched: change how RT task is picked in pull_rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <BANLkTimPjYmnBjvRc8Q2hUxiAw3bbr3FRA@mail.gmail.com>
Date:	Sat, 21 May 2011 00:44:51 +0800
From:	Hillf Danton <dhillf@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mike Galbraith <efault@....de>,
	Yong Zhang <yong.zhang0@...il.com>
Subject: [PATCH v0] sched: change how RT task is picked in pull_rt_task()

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@...il.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);
 	}
--
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/