[TIP/SCHED/DEVEL PATCH v3 3/6] sched: make double-lock-balance fair

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Gregory Haskins
Date: Thursday, September 4, 2008 - 5:55 am

double_lock balance() currently favors logically lower cpus since they
often do not have to release their own lock to acquire a second lock.
The result is that logically higher cpus can get starved when there is
a lot of pressure on the RQs.  This can result in higher latencies on
higher cpu-ids.

This patch makes the algorithm more fair by forcing all paths to have
to release both locks before acquiring them again.  Since callsites to
double_lock_balance already consider it a potential preemption/reschedule
point, they have the proper logic to recheck for atomicity violations.

Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---

 kernel/sched.c |   52 +++++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 35e1f21..af4c6fa 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2782,21 +2782,43 @@ static void double_rq_unlock(struct rq *rq1, struct rq *rq2)
 		__release(rq2->lock);
 }
 
+#ifdef CONFIG_PREEMPT
+
 /*
- * double_lock_balance - lock the busiest runqueue, this_rq is locked already.
+ * fair double_lock_balance: Safely acquires both rq->locks in a fair
+ * way at the expense of forcing extra atomic operations in all
+ * invocations.  This assures that the double_lock is acquired using the
+ * same underlying policy as the spinlock_t on this architecture, which
+ * reduces latency compared to the unfair variant below.  However, it
+ * also adds more overhead and therefore may reduce throughput.
  */
-static int double_lock_balance(struct rq *this_rq, struct rq *busiest)
+static inline int _double_lock_balance(struct rq *this_rq, struct rq *busiest)
+	__releases(this_rq->lock)
+	__acquires(busiest->lock)
+	__acquires(this_rq->lock)
+{
+	spin_unlock(&this_rq->lock);
+	double_rq_lock(this_rq, busiest);
+
+	return 1;
+}
+
+#else
+
+/*
+ * Unfair double_lock_balance: Optimizes throughput at the expense of
+ * latency by eliminating extra atomic operations when the locks are
+ * already in proper order on entry.  This favors lower cpu-ids and will
+ * grant the double lock to lower cpus over higher ids under contention,
+ * regardless of entry order into the function.
+ */
+static inline int _double_lock_balance(struct rq *this_rq, struct rq *busiest)
 	__releases(this_rq->lock)
 	__acquires(busiest->lock)
 	__acquires(this_rq->lock)
 {
 	int ret = 0;
 
-	if (unlikely(!irqs_disabled())) {
-		/* printk() doesn't work good under rq->lock */
-		spin_unlock(&this_rq->lock);
-		BUG_ON(1);
-	}
 	if (unlikely(!spin_trylock(&busiest->lock))) {
 		if (busiest < this_rq) {
 			spin_unlock(&this_rq->lock);
@@ -2809,6 +2831,22 @@ static int double_lock_balance(struct rq *this_rq, struct rq *busiest)
 	return ret;
 }
 
+#endif /* CONFIG_PREEMPT */
+
+/*
+ * double_lock_balance - lock the busiest runqueue, this_rq is locked already.
+ */
+static int double_lock_balance(struct rq *this_rq, struct rq *busiest)
+{
+	if (unlikely(!irqs_disabled())) {
+		/* printk() doesn't work good under rq->lock */
+		spin_unlock(&this_rq->lock);
+		BUG_ON(1);
+	}
+
+	return _double_lock_balance(this_rq, busiest);
+}
+
 static void double_unlock_balance(struct rq *this_rq, struct rq *busiest)
 	__releases(busiest->lock)
 {

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 0/5] sched: misc rt fixes for tip/sched/devel, Gregory Haskins, (Mon Aug 25, 1:15 pm)
[PATCH 3/5] sched: make double-lock-balance fair, Gregory Haskins, (Mon Aug 25, 1:15 pm)
Re: [PATCH 3/5] sched: make double-lock-balance fair, Nick Piggin, (Mon Aug 25, 11:14 pm)
Re: [PATCH 3/5] sched: make double-lock-balance fair, Gregory Haskins, (Tue Aug 26, 5:23 am)
[PATCH v2 0/6] Series short description, Gregory Haskins, (Tue Aug 26, 10:34 am)
[PATCH v2 3/6] sched: make double-lock-balance fair, Gregory Haskins, (Tue Aug 26, 10:35 am)
Re: [PATCH 3/5] sched: make double-lock-balance fair, Nick Piggin, (Tue Aug 26, 11:36 pm)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Peter Zijlstra, (Wed Aug 27, 1:21 am)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Peter Zijlstra, (Wed Aug 27, 1:25 am)
Re: [PATCH v2 0/6] Series short description, Peter Zijlstra, (Wed Aug 27, 1:33 am)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Peter Zijlstra, (Wed Aug 27, 3:41 am)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Peter Zijlstra, (Wed Aug 27, 4:07 am)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Russell King, (Wed Aug 27, 4:17 am)
Re: [PATCH 3/5] sched: make double-lock-balance fair, Gregory Haskins, (Wed Aug 27, 4:41 am)
Re: [PATCH 3/5] sched: make double-lock-balance fair, Nick Piggin, (Wed Aug 27, 4:53 am)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Gregory Haskins, (Wed Aug 27, 5:00 am)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Gregory Haskins, (Wed Aug 27, 5:02 am)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Gregory Haskins, (Wed Aug 27, 5:03 am)
Re: [PATCH 3/5] sched: make double-lock-balance fair, Gregory Haskins, (Wed Aug 27, 5:10 am)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Gregory Haskins, (Wed Aug 27, 5:13 am)
Re: [PATCH v2 3/6] sched: make double-lock-balance fair, Ralf Baechle, (Fri Aug 29, 5:49 am)
[TIP/SCHED/DEVEL PATCH v3 0/6] sched: misc rt fixes, Gregory Haskins, (Thu Sep 4, 5:54 am)
[TIP/SCHED/DEVEL PATCH v3 3/6] sched: make double-lock-bal ..., Gregory Haskins, (Thu Sep 4, 5:55 am)