From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753583AbdASQdH (ORCPT ); Thu, 19 Jan 2017 11:33:07 -0500 Received: from smtprelay0145.hostedemail.com ([216.40.44.145]:46585 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753535AbdASQci (ORCPT ); Thu, 19 Jan 2017 11:32:38 -0500 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::,RULES_HIT:41:355:379:541:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2393:2559:2562:3138:3139:3140:3141:3142:3352:3673:3865:3866:3868:3870:3871:3872:3874:4321:5007:6261:7774:7903:10004:10400:10848:11026:11658:11914:12050:12296:12438:12555:12760:12986:13069:13161:13229:13311:13357:13439:13868:14096:14097:14181:14394:14659:14721:21080:21212:21451:30012:30045:30054:30070,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:6,LUA_SUMMARY:none X-HE-Tag: army75_50ec31538fa60 X-Filterd-Recvd-Size: 2072 Date: Thu, 19 Jan 2017 11:32:34 -0500 From: "Steven Rostedt (VMware)" To: LKML Cc: Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Andrew Morton Subject: [PATCH] rtmutex: rt_mutex_slowlock() is mostly called as TASK_INTERRUPTIBLE Message-ID: <20170119113234.1efeedd1@gandalf.local.home> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) --- diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 1ec0f48..8de6288 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -1115,7 +1115,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;