From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753268AbdA3Lx4 (ORCPT ); Mon, 30 Jan 2017 06:53:56 -0500 Received: from terminus.zytor.com ([65.50.211.136]:47504 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751360AbdA3Lxy (ORCPT ); Mon, 30 Jan 2017 06:53:54 -0500 Date: Mon, 30 Jan 2017 03:53:18 -0800 From: "tip-bot for Steven Rostedt (VMware)" Message-ID: Cc: akpm@linux-foundation.org, hpa@zytor.com, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, mingo@kernel.org, tglx@linutronix.de, rostedt@goodmis.org, peterz@infradead.org Reply-To: peterz@infradead.org, rostedt@goodmis.org, tglx@linutronix.de, mingo@kernel.org, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, hpa@zytor.com, akpm@linux-foundation.org In-Reply-To: <20170119113234.1efeedd1@gandalf.local.home> References: <20170119113234.1efeedd1@gandalf.local.home> To: linux-tip-commits@vger.kernel.org Subject: [tip:locking/core] locking/rtmutex: Flip unlikely() branch to likely() in __rt_mutex_slowlock() Git-Commit-ID: 4009f4b3a9d8b74547269f293e6a920adf278996 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 4009f4b3a9d8b74547269f293e6a920adf278996 Gitweb: http://git.kernel.org/tip/4009f4b3a9d8b74547269f293e6a920adf278996 Author: Steven Rostedt (VMware) AuthorDate: Thu, 19 Jan 2017 11:32:34 -0500 Committer: Ingo Molnar CommitDate: Mon, 30 Jan 2017 11:42:59 +0100 locking/rtmutex: Flip unlikely() branch to likely() in __rt_mutex_slowlock() 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) Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20170119113234.1efeedd1@gandalf.local.home Signed-off-by: Ingo Molnar --- kernel/locking/rtmutex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 2f443ed..d340be3 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -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;