Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753597AbbGAW2B (ORCPT ); Wed, 1 Jul 2015 18:28:01 -0400 Received: from www.linutronix.de ([62.245.132.108]:40589 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752069AbbGAW1x (ORCPT ); Wed, 1 Jul 2015 18:27:53 -0400 Date: Thu, 2 Jul 2015 00:27:39 +0200 (CEST) From: Thomas Gleixner To: Davidlohr Bueso cc: Ingo Molnar , Peter Zijlstra , Darren Hart , Steven Rostedt , Mike Galbraith , "Paul E. McKenney" , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH -tip v2 1/2] locking/rtmutex: Support spin on owner In-Reply-To: <1435782588-4177-1-git-send-email-dave@stgolabs.net> Message-ID: References: <1435782588-4177-1-git-send-email-dave@stgolabs.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2693 Lines: 77 On Wed, 1 Jul 2015, Davidlohr Bueso wrote: > Similar to what we have in other locks, particularly regular mutexes, the > idea is that as long as the owner is running, there is a fair chance it'll > release the lock soon, and thus a task trying to acquire the rtmutex will > better off spinning instead of blocking immediately after the fastpath. > Conditions to stop spinning and enter the slowpath are simple: > > (1) Upon need_resched() > (2) Current lock owner blocks > > Because rtmutexes track the lock owner atomically, we can extend the fastpath > to continue polling on the lock owner via cmpxchg(lock->owner, NULL, current). > > However, this is a conservative approach, such that if there are any waiters > in-line, we stop spinning and immediately take the traditional slowpath. This > allows priority boosting to take precedence over spinning, as otherwise we > could starve a higher priority queued-up task (ie: top waiter) if spinners > constantly steal the lock. I'm a bit wary about the whole approach. In the RT tree we spin AFTER we've enqueued the waiter and run priority boosting. While I can see the charm of your approach, i.e. avoiding the prio boost dance for the simple case, this can introduce larger latencies. T1 (prio = 0) T2 (prio = 50) lock(RTM); lock(RTM); spin() -->preemption T3 (prio = 10) leave spin, because owner is not on cpu enqueue(); boost(); schedule(); -->preemption T1 (prio = 50) So we trade two extra context switches in the worst case for an enhancement of performance in the normal case. I cannot quantify the impact of this, but we really need to evaluate that proper before going there. Aside of that, if the lock is really contended, then you force all spinners off the cpu, if one of the spinners starts blocking simply because you have no idea which one is the top prio spinner. T1 (prio = 0) T2 (prio = 50) T3 (prio = 10) lock(RTM); lock(RTM); lock(RTM); spin() spin(); --> preemption enqueue() boost(); schedule(); sees waiter bit enqueue(); boost(); schedule(); T2 could happily keep spinning despite T3 going to sleep. I'm not sure if that's what we want to achieve. Need to think about it some more, but I wanted to give you something to think about as well :) Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/