All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org, "Chen,
	Kenneth W" <kenneth.w.chen@intel.com>,
	"'Chris Mason'" <mason@suse.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH RFC] smt nice introduces significant lock contention
Date: Fri, 02 Jun 2006 18:28:40 +1000	[thread overview]
Message-ID: <447FF6B8.1000700@yahoo.com.au> (raw)
In-Reply-To: <200606021817.46745.kernel@kolivas.org>

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

Con Kolivas wrote:
> On Friday 02 June 2006 17:53, Nick Piggin wrote:
> 
>>This is a small micro-optimisation / cleanup we can do after
>>smtnice gets converted to use trylocks. Might result in a little
>>less cacheline footprint in some cases.
> 
> 
> It's only dependent_sleeper that is being converted in these patches. The 
> wake_sleeping_dependent component still locks all runqueues and needs to 

Oh I missed that.

> succeed in order to ensure a task doesn't keep sleeping indefinitely. That 

Let's make it use trylocks as well. wake_priority_sleeper should ensure
things don't sleep forever I think? We should be optimising for the most
common case, and in many workloads, the runqueue does go idle frequently.

> one doesn't get called from schedule() so is far less expensive. This means I 
> don't think we can change that cpu based locking order which I believe was 
> introduce to prevent a deadlock (?DaveJ disovered it iirc).
> 

AntonB, I think.

-- 
SUSE Labs, Novell Inc.

[-- Attachment #2: sntnice2.patch --]
[-- Type: text/plain, Size: 1843 bytes --]

Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c	2006-06-02 18:23:18.000000000 +1000
+++ linux-2.6/kernel/sched.c	2006-06-02 18:26:40.000000000 +1000
@@ -2686,6 +2686,9 @@ static inline void wakeup_busy_runqueue(
 		resched_task(rq->idle);
 }
 
+/*
+ * Called with interrupts disabled and this_rq's runqueue locked.
+ */
 static void wake_sleeping_dependent(int this_cpu, runqueue_t *this_rq)
 {
 	struct sched_domain *tmp, *sd = NULL;
@@ -2699,22 +2702,13 @@ static void wake_sleeping_dependent(int 
 	if (!sd)
 		return;
 
-	/*
-	 * Unlock the current runqueue because we have to lock in
-	 * CPU order to avoid deadlocks. Caller knows that we might
-	 * unlock. We keep IRQs disabled.
-	 */
-	spin_unlock(&this_rq->lock);
-
 	sibling_map = sd->span;
-
-	for_each_cpu_mask(i, sibling_map)
-		spin_lock(&cpu_rq(i)->lock);
-	/*
-	 * We clear this CPU from the mask. This both simplifies the
-	 * inner loop and keps this_rq locked when we exit:
-	 */
 	cpu_clear(this_cpu, sibling_map);
+	for_each_cpu_mask(i, sibling_map) {
+		if (unlikely(!spin_trylock(&cpu_rq(i)->lock)))
+			cpu_clear(i, sibling_map);
+	}
+
 
 	for_each_cpu_mask(i, sibling_map) {
 		runqueue_t *smt_rq = cpu_rq(i);
@@ -2724,10 +2718,6 @@ static void wake_sleeping_dependent(int 
 
 	for_each_cpu_mask(i, sibling_map)
 		spin_unlock(&cpu_rq(i)->lock);
-	/*
-	 * We exit with this_cpu's rq still held and IRQs
-	 * still disabled:
-	 */
 }
 
 /*
@@ -2961,13 +2951,6 @@ need_resched_nonpreemptible:
 			next = rq->idle;
 			rq->expired_timestamp = 0;
 			wake_sleeping_dependent(cpu, rq);
-			/*
-			 * wake_sleeping_dependent() might have released
-			 * the runqueue, so break out if we got new
-			 * tasks meanwhile:
-			 */
-			if (!rq->nr_running)
-				goto switch_tasks;
 		}
 	}
 

  reply	other threads:[~2006-06-02  8:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-01 22:55 [PATCH RFC] smt nice introduces significant lock contention Chris Mason
2006-06-01 23:57 ` Chen, Kenneth W
2006-06-02  1:59   ` Con Kolivas
2006-06-02  2:28     ` Con Kolivas
2006-06-02  3:55       ` Con Kolivas
2006-06-02  4:18         ` Nick Piggin
2006-06-02  6:08           ` Con Kolivas
2006-06-02  7:53             ` Nick Piggin
2006-06-02  8:17               ` Con Kolivas
2006-06-02  8:28                 ` Nick Piggin [this message]
2006-06-02  8:34                   ` Chen, Kenneth W
2006-06-02  8:56                     ` Nick Piggin
2006-06-02  9:17                       ` Chen, Kenneth W
2006-06-02  9:25                         ` Con Kolivas
2006-06-02  9:31                           ` Chen, Kenneth W
2006-06-02  9:34                             ` Con Kolivas
2006-06-02  9:53                               ` Chen, Kenneth W
2006-06-02 10:12                                 ` Con Kolivas
2006-06-02 20:53                                   ` Chen, Kenneth W
2006-06-02 22:15                                     ` Con Kolivas
2006-06-02 22:19                                       ` Chen, Kenneth W
2006-06-02 22:31                                         ` Con Kolivas
2006-06-02 22:58                                           ` Chen, Kenneth W
2006-06-03  0:02                                             ` Con Kolivas
2006-06-03  0:08                                               ` Chen, Kenneth W
2006-06-03  0:27                                                 ` Con Kolivas
2006-06-02  9:36                       ` Chen, Kenneth W
2006-06-02 10:30                       ` Con Kolivas
2006-06-02 13:16                         ` Con Kolivas
2006-06-02 21:54                           ` Chen, Kenneth W
2006-06-02 22:04                             ` Con Kolivas
2006-06-02 22:14                       ` Chen, Kenneth W
2006-06-02 10:19                   ` Con Kolivas
2006-06-02 20:59                     ` Chen, Kenneth W
2006-06-02  8:38               ` Chen, Kenneth W
2006-06-02  8:24           ` Chen, Kenneth W
2006-06-02  8:31         ` Chen, Kenneth W
2006-06-02  8:50         ` Chen, Kenneth W
2006-06-02  2:35     ` Chen, Kenneth W
2006-06-02  3:04       ` Con Kolivas
2006-06-02  3:23         ` Con Kolivas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=447FF6B8.1000700@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=kenneth.w.chen@intel.com \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mason@suse.com \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.