linux-kernel - Re: [RFC] rtmutex: Do not boost fair tasks each other

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1401396751.1628.4.camel@localhost.localdomain>
Date:	Fri, 30 May 2014 00:52:31 +0400
From:	Kirill Tkhai <tkhai@...dex.ru>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Mike Galbraith <umgwanakikbuti@...il.com>
Subject: Re: [RFC] rtmutex: Do not boost fair tasks each other

В Ср, 28/05/2014 в 22:26 +0200, Thomas Gleixner пишет:
> On Mon, 5 May 2014, Kirill Tkhai wrote:
> > В Сб, 03/05/2014 в 20:54 +0200, Thomas Gleixner пишет:
> > > Though exercising that code path as much as we can is not a bad thing
> > > either. So I'd like to see that made compile time conditional on one
> > > of the lock testing CONFIG items.
> >  

> > +#ifndef CONFIG_RT_MUTEX_BOOST_ALL
> 
> No, not another pointless config option. Read what I said. What's
> wrong with using an existing config item, e.g DEBUG_RT_MUTEXES?
> 
> > +#define heritable_prio(prio)		(rt_prio(prio) || dl_prio(prio))
> 
> inheritable please. It's not priority heritance and never will be.

Thanks for comments. Here is new version.

[PATCH] rtmutex: Do not boost owner's prio if waiter is SCHED_OTHER

Higher priority does not provide exclusive privilege
of one fair class task over the other. In this case
priority boosting is pointless, and it may worsen
performance.

This patch makes boosting, which is requested by fair
class waiters, optional. It's disabled by default, but
it's possible to enable it for debugging purposes to
have more cases of priority inheritance.

Signed-off-by: Kirill Tkhai <tkhai@...dex.ru>

 kernel/locking/rtmutex.c | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index aa4dff0..fa6a9b3 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -189,6 +189,13 @@ rt_mutex_dequeue_pi(struct task_struct *task, struct rt_mutex_waiter *waiter)
 	RB_CLEAR_NODE(&waiter->pi_tree_entry);
 }
 
+#ifndef CONFIG_DEBUG_RT_MUTEXES
+#define inheritable_prio(prio)	(rt_prio(prio) || dl_prio(prio))
+#else
+/* We want to have more cases of priority boosting */
+#define inheritable_prio(prio)	(1)
+#endif
+
 /*
  * Calculate task priority from the waiter tree priority
  *
@@ -197,11 +204,14 @@ rt_mutex_dequeue_pi(struct task_struct *task, struct rt_mutex_waiter *waiter)
  */
 int rt_mutex_getprio(struct task_struct *task)
 {
-	if (likely(!task_has_pi_waiters(task)))
-		return task->normal_prio;
+	if (unlikely(task_has_pi_waiters(task))) {
+		int prio = task_top_pi_waiter(task)->prio;
+
+		if (inheritable_prio(prio))
+			return min(prio, task->normal_prio);
+	}
 
-	return min(task_top_pi_waiter(task)->prio,
-		   task->normal_prio);
+	return task->normal_prio;
 }
 
 struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
@@ -218,10 +228,14 @@ struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
  */
 int rt_mutex_check_prio(struct task_struct *task, int newprio)
 {
-	if (!task_has_pi_waiters(task))
-		return 0;
+	if (unlikely(task_has_pi_waiters(task))) {
+		int prio = task_top_pi_waiter(task)->task->prio;
 
-	return task_top_pi_waiter(task)->task->prio <= newprio;
+		if (inheritable_prio(prio))
+			return prio <= newprio;
+	}
+
+	return 0;
 }
 
 /*



--
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/