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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTimF2d93VVGKHDdFTn=V-1h9nWrs_w@mail.gmail.com>
Date:	Sat, 21 May 2011 23:28:19 +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 run-queue is selected for RT task

When selecting run-queue for a given RT task, we have to take a few
factors, such as task priority and CPU cache affinity, into
consideration. In this work, a simpler method is proposed, which is
focusing on the relation between the current run-queue of the given
task and the given run-queue.

If the current run-queue of task is the given run-queue, the run-queue
of task keeps unchanged, so the CPU cache affinities of both task and
the current task of run-queue remain unchanged. Then there are at
least two tasks competing one CPU, and in the worst case that both
competitors are RT tasks the victim will be selected and processed by
pusher later.

On other hand, if the current run-queue of task is different from the
given run-queue, task is simply delivered to its current run-queue,
since pusher is always willing to do hard works.

In summary, the burden of RT task is always processed first by the
pusher of its current run-queue.

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 22:19:52.000000000 +0800
@@ -998,14 +998,12 @@ select_task_rq_rt(struct rq *rq, struct
 	 *
 	 * For equal prio tasks, we just let the scheduler sort it out.
 	 */
-	if (unlikely(rt_task(rq->curr)) &&
-	    (rq->curr->rt.nr_cpus_allowed < 2 ||
-	     rq->curr->prio < p->prio) &&
-	    (p->rt.nr_cpus_allowed > 1)) {
-		int cpu = find_lowest_rq(p);

-		return (cpu == -1) ? task_cpu(p) : cpu;
-	}
+	if (task_cpu(p) == rq->cpu)
+		return rq->cpu;
+
+	if (likely(!rt_task(rq->curr)))
+		return rq->cpu;

 	/*
 	 * Otherwise, just let it ride on the affined RQ and the
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ