All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Shi <alex.shi@linaro.org>
To: peterz@infradead.org, mingo@redhat.com, corbet@lwn.net,
	linux-kernel@vger.kernel.org (open list:LOCKING PRIMITIVES)
Cc: linux-kernel@vger.kernel.org, Alex Shi <alex.shi@linaro.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sebastian Siewior <bigeasy@linutronix.de>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: [PATCH 2/3] rtmutex: deboost priority conditionally when rt-mutex unlock
Date: Thu, 13 Apr 2017 22:02:53 +0800	[thread overview]
Message-ID: <1492092174-31734-3-git-send-email-alex.shi@linaro.org> (raw)
In-Reply-To: <1492092174-31734-1-git-send-email-alex.shi@linaro.org>

The rt_mutex_fastunlock() will deboost 'current' task when it should be.
but the rt_mutex_slowunlock() function will set the 'deboost' flag
unconditionally. That cause some unnecessary priority adjustment.

'current' release this lock, so 'current' should be a higher prio
task than the next top waiter, unless the current prio was gotten
from this top waiter, iff so, we need to deboost 'current' after
the lock release.

Signed-off-by: Alex Shi <alex.shi@linaro.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
To: linux-kernel@vger.kernel.org
To: Ingo Molnar <mingo@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 kernel/locking/rtmutex.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 6edc32e..05ff685 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1037,10 +1037,11 @@ static int task_blocks_on_rt_mutex(struct rt_mutex *lock,
  *
  * Called with lock->wait_lock held and interrupts disabled.
  */
-static void mark_wakeup_next_waiter(struct wake_q_head *wake_q,
+static bool mark_wakeup_next_waiter(struct wake_q_head *wake_q,
 				    struct rt_mutex *lock)
 {
 	struct rt_mutex_waiter *waiter;
+	bool deboost = false;
 
 	raw_spin_lock(&current->pi_lock);
 
@@ -1055,6 +1056,15 @@ static void mark_wakeup_next_waiter(struct wake_q_head *wake_q,
 	rt_mutex_dequeue_pi(current, waiter);
 
 	/*
+	 * 'current' release this lock, so 'current' should be a higher prio
+	 * task than the next top waiter, unless the current prio was gotten
+	 * from this top waiter, iff so, we need to deboost 'current' after
+	 * the lock release.
+	 */
+	if (current->prio == waiter->prio)
+		deboost = true;
+
+	/*
 	 * As we are waking up the top waiter, and the waiter stays
 	 * queued on the lock until it gets the lock, this lock
 	 * obviously has waiters. Just set the bit here and this has
@@ -1067,6 +1077,8 @@ static void mark_wakeup_next_waiter(struct wake_q_head *wake_q,
 	raw_spin_unlock(&current->pi_lock);
 
 	wake_q_add(wake_q, waiter->task);
+
+	return deboost;
 }
 
 /*
@@ -1336,6 +1348,7 @@ static bool __sched rt_mutex_slowunlock(struct rt_mutex *lock,
 					struct wake_q_head *wake_q)
 {
 	unsigned long flags;
+	bool deboost = false;
 
 	/* irqsave required to support early boot calls */
 	raw_spin_lock_irqsave(&lock->wait_lock, flags);
@@ -1389,12 +1402,12 @@ static bool __sched rt_mutex_slowunlock(struct rt_mutex *lock,
 	 *
 	 * Queue the next waiter for wakeup once we release the wait_lock.
 	 */
-	mark_wakeup_next_waiter(wake_q, lock);
+	deboost = mark_wakeup_next_waiter(wake_q, lock);
 
 	raw_spin_unlock_irqrestore(&lock->wait_lock, flags);
 
 	/* check PI boosting */
-	return true;
+	return deboost;
 }
 
 /*
-- 
1.9.1

  parent reply	other threads:[~2017-04-13 14:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-13 14:02 [RFC PATCH 0/3] rtmutex comments update and trival fix Alex Shi
2017-04-13 14:02 ` [PATCH 1/3] rtmutex: comments update Alex Shi
2017-04-13 15:54   ` Steven Rostedt
2017-04-14  8:52     ` Alex Shi
2017-04-14 18:43       ` Steven Rostedt
2017-04-18  8:38         ` Alex Shi
2017-04-13 16:00   ` Steven Rostedt
2017-04-13 14:02 ` Alex Shi [this message]
2017-04-13 14:23   ` [PATCH 2/3] rtmutex: deboost priority conditionally when rt-mutex unlock Sebastian Siewior
2017-04-13 14:39   ` Peter Zijlstra
2017-04-13 16:09     ` Steven Rostedt
2017-04-13 16:21       ` Peter Zijlstra
2017-04-13 16:40         ` Steven Rostedt
2017-04-13 16:51           ` Peter Zijlstra
2017-04-13 14:02 ` [PATCH 3/3] rtmutex: remove unnecessary adjust prio Alex Shi
2017-04-13 16:15   ` Steven Rostedt

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=1492092174-31734-3-git-send-email-alex.shi@linaro.org \
    --to=alex.shi@linaro.org \
    --cc=bigeasy@linutronix.de \
    --cc=corbet@lwn.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --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 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.