public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Gregory Haskins <ghaskins@novell.com>,
	Peter Morreale <pmorreale@novell.com>
Subject: [RFC][RT][PATCH 3/4] rtmutex: Revert Optimize rt lock wakeup
Date: Thu, 23 Dec 2010 17:47:58 -0500	[thread overview]
Message-ID: <20101223225116.729981172@goodmis.org> (raw)
In-Reply-To: 20101223224755.078983538@goodmis.org

[-- Attachment #1: 0003-rtmutex-Revert-Optimize-rt-lock-wakeup.patch --]
[-- Type: text/plain, Size: 2377 bytes --]

From: Steven Rostedt <srostedt@redhat.com>

The commit: rtmutex: Optimize rt lock wakeup

Does not do what it was suppose to do.
This is because the adaptive waiter sets its state to TASK_(UN)INTERRUPTIBLE
before going into the loop. Thus, the test in wakeup_next_waiter()
will always fail on an adaptive waiter, as it only tests to see if
the pending waiter never has its state set ot TASK_RUNNING unless
something else had woke it up.

The smp_mb() added to make this test work is just as expensive as
just calling wakeup. And since we we fail to wake up anyway, we are
doing both a smp_mb() and wakeup as well.

I tested this with dbench and we run faster without this patch.
I also tried a variant that instead fixed the loop, to change the state
only if the spinner was to go to sleep, and that still did not show
any improvement.

Cc: Gregory Haskins <ghaskins@novell.com>
Cc: Peter Morreale <pmorreale@novell.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/rtmutex.c |   29 ++---------------------------
 1 files changed, 2 insertions(+), 27 deletions(-)

diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 318d7ed..e218873 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -554,33 +554,8 @@ static void wakeup_next_waiter(struct rt_mutex *lock, int savestate)
 	 */
 	if (!savestate)
 		wake_up_process(pendowner);
-	else {
-		/*
-		 * We can skip the actual (expensive) wakeup if the
-		 * waiter is already running, but we have to be careful
-		 * of race conditions because they may be about to sleep.
-		 *
-		 * The waiter-side protocol has the following pattern:
-		 * 1: Set state != RUNNING
-		 * 2: Conditionally sleep if waiter->task != NULL;
-		 *
-		 * And the owner-side has the following:
-		 * A: Set waiter->task = NULL
-		 * B: Conditionally wake if the state != RUNNING
-		 *
-		 * As long as we ensure 1->2 order, and A->B order, we
-		 * will never miss a wakeup.
-		 *
-		 * Therefore, this barrier ensures that waiter->task = NULL
-		 * is visible before we test the pendowner->state.  The
-		 * corresponding barrier is in the sleep logic.
-		 */
-		smp_mb();
-
-		/* If !RUNNING && !RUNNING_MUTEX */
-		if (pendowner->state & ~TASK_RUNNING_MUTEX)
-			wake_up_process_mutex(pendowner);
-	}
+	else
+		wake_up_process_mutex(pendowner);
 
 	rt_mutex_set_owner(lock, pendowner, RT_MUTEX_OWNER_PENDING);
 
-- 
1.7.2.3



  parent reply	other threads:[~2010-12-23 22:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-23 22:47 [RFC][RT][PATCH 0/4] rtmutex: Simplify PI code Steven Rostedt
2010-12-23 22:47 ` [RFC][RT][PATCH 1/4] rtmutex: Only save lock depth once in spin_slowlock Steven Rostedt
2010-12-23 22:47 ` [RFC][RT][PATCH 2/4] rtmutex: Try to take lock early in rt_spin_lock_slowlock() Steven Rostedt
2010-12-23 22:47 ` Steven Rostedt [this message]
2010-12-24  4:45   ` [RFC][RT][PATCH 3/4] rtmutex: Revert Optimize rt lock wakeup Gregory Haskins
2010-12-24  4:54     ` Steven Rostedt
2010-12-28 14:06       ` Gregory Haskins
2011-01-03 19:06         ` Steven Rostedt
2011-01-03 20:22           ` Steven Rostedt
2011-01-04 15:19             ` Peter W. Morreale
2011-01-04 15:47               ` Steven Rostedt
2011-01-04 17:15                 ` Peter W. Morreale
2011-01-04 17:27                   ` Steven Rostedt
2011-01-04 17:45                     ` Peter W. Morreale
2011-01-04 18:06                       ` Steven Rostedt
2011-01-04 20:48                         ` Peter W. Morreale
2011-01-04 17:24                 ` Peter W. Morreale
2011-01-10 14:49           ` Gregory Haskins
     [not found]   ` <4D13DF250200005A000793E1@novell.com>
2010-12-24 15:47     ` Peter W. Morreale
2010-12-23 22:47 ` [RFC][RT][PATCH 4/4] rtmutex: Ensure only the top waiter or higher priority task can take the lock Steven Rostedt
2011-01-04  4:02   ` Steven Rostedt
2011-01-05  7:12     ` Lai Jiangshan

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=20101223225116.729981172@goodmis.org \
    --to=rostedt@goodmis.org \
    --cc=ghaskins@novell.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=pmorreale@novell.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox