[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080825201529.23217.8708.stgit@dev.haskins.net>
Date: Mon, 25 Aug 2008 16:15:29 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: mingo@...e.hu
Cc: srostedt@...hat.com, peterz@...radead.org,
linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
npiggin@...e.de, gregory.haskins@...il.com
Subject: [PATCH 2/5] sched: pull only one task during NEWIDLE balancing to
limit critical section
git-id c4acb2c0669c5c5c9b28e9d02a34b5c67edf7092 attempted to limit
newidle critical section length by stopping after at least one task
was moved. Further investigation has shown that there are other
paths nested further inside the algorithm which still remain that allow
long latencies to occur with newidle balancing. This patch applies
the same technique inside balance_tasks() to limit the duration of
this optional balancing operation.
Signed-off-by: Gregory Haskins <ghaskins@...ell.com>
CC: Nick Piggin <npiggin@...e.de>
---
kernel/sched.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 6a43c89..6e0bde6 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2963,9 +2963,11 @@ next:
rem_load_move -= p->se.load.weight;
/*
- * We only want to steal up to the prescribed amount of weighted load.
+ * We only want to steal up to the prescribed amount of weighted load
+ * and we don't want to take more than one task if we are NEWLY idle
+ * since this can cause unbounded latencies
*/
- if (rem_load_move > 0) {
+ if (idle != CPU_NEWLY_IDLE && rem_load_move > 0) {
if (p->prio < *this_best_prio)
*this_best_prio = p->prio;
p = iterator->next(iterator->arg);
--
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