OSDN Git Service

locking/rtmutex: Flip unlikely() branch to likely() in __rt_mutex_slowlock()
authorSteven Rostedt (VMware) <rostedt@goodmis.org>
Thu, 19 Jan 2017 16:32:34 +0000 (11:32 -0500)
committer0ranko0P <ranko0p@outlook.com>
Tue, 24 Dec 2019 20:42:45 +0000 (04:42 +0800)
Running my likely/unlikely profiler for 3 weeks on two production
machines, I discovered that the unlikely() test in
__rt_mutex_slowlock() checking if state is TASK_INTERRUPTIBLE is hit
100% of the time, making it a very likely case.

The reason is, on a vanilla kernel, the majority case of calling
rt_mutex() is from the futex code. This code is always called as
TASK_INTERRUPTIBLE. In the -rt patch, this code is commonly called when
PREEMPT_RT is enabled with TASK_UNINTERRUPTIBLE. But that's not the
likely scenario.

The rt_mutex() code should be optimized for the common vanilla case,
and that is from a futex, with TASK_INTERRUPTIBLE as the state.

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170119113234.1efeedd1@gandalf.local.home
Signed-off-by: Ingo Molnar <mingo@kernel.org>
kernel/locking/rtmutex.c

index 3927738..a5964c8 100644 (file)
@@ -1179,7 +1179,7 @@ __rt_mutex_slowlock(struct rt_mutex *lock, int state,
                 * TASK_INTERRUPTIBLE checks for signals and
                 * timeout. Ignored otherwise.
                 */
-               if (unlikely(state == TASK_INTERRUPTIBLE)) {
+               if (likely(state == TASK_INTERRUPTIBLE)) {
                        /* Signal pending? */
                        if (signal_pending(current))
                                ret = -EINTR;