summaryrefslogtreecommitdiffstats
path: root/drivers/video
diff options
context:
space:
mode:
authorSteven Rostedt (VMware)2017-01-19 17:32:34 +0100
committerIngo Molnar2017-01-30 11:42:59 +0100
commit4009f4b3a9d8b74547269f293e6a920adf278996 (patch)
treed89abc6ec739d45d9f24a4684af2275ffa62fced /drivers/video
parentlocking/rwsem: Reinit wake_q after use (diff)
downloadkernel-qcow2-linux-4009f4b3a9d8b74547269f293e6a920adf278996.tar.gz
kernel-qcow2-linux-4009f4b3a9d8b74547269f293e6a920adf278996.tar.xz
kernel-qcow2-linux-4009f4b3a9d8b74547269f293e6a920adf278996.zip
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) <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>
Diffstat (limited to 'drivers/video')
0 files changed, 0 insertions, 0 deletions