From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757948Ab2CHVon (ORCPT ); Thu, 8 Mar 2012 16:44:43 -0500 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:4058 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757767Ab2CHVoj (ORCPT ); Thu, 8 Mar 2012 16:44:39 -0500 X-Authority-Analysis: v=2.0 cv=Wf+OmjdX c=1 sm=0 a=ZycB6UtQUfgMyuk2+PxD7w==:17 a=XQbtiDEiEegA:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10 a=anWZLHutpBUnYfsKbQAA:9 a=8RIOfjV1VssmndXOg9YA:7 a=PUjeQqilurYA:10 a=ZycB6UtQUfgMyuk2+PxD7w==:117 X-Cloudmark-Score: 0 X-Originating-IP: 74.67.80.29 Message-ID: <1331243078.25686.510.camel@gandalf.stny.rr.com> Subject: Re: [ANNOUNCE] 3.2.9-rt17 From: Steven Rostedt To: Peter Zijlstra Cc: Thomas Gleixner , LKML , linux-rt-users Date: Thu, 08 Mar 2012 16:44:38 -0500 In-Reply-To: <1331242625.11248.433.camel@twins> References: <1331230991.25686.452.camel@gandalf.stny.rr.com> <1331231287.11248.396.camel@twins> <1331232159.25686.456.camel@gandalf.stny.rr.com> <1331235579.11248.402.camel@twins> <1331237441.25686.469.camel@gandalf.stny.rr.com> <1331238369.11248.426.camel@twins> <1331240882.25686.499.camel@gandalf.stny.rr.com> <1331241627.11248.430.camel@twins> <1331241940.25686.502.camel@gandalf.stny.rr.com> <1331242104.11248.432.camel@twins> <1331242574.25686.505.camel@gandalf.stny.rr.com> <1331242625.11248.433.camel@twins> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.2.2-1 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2012-03-08 at 22:37 +0100, Peter Zijlstra wrote: > > Now when the original task releases the lock again, the other task can > > take it just like it does on mainline. > > Now interleave it with a third task of even higher priority that puts > the spinner to sleep. So? It will eventually have to allow the task to run. Adding a "third higher priority" task can cause problems in any other part of the -rt kernel. We don't need to worry about priority inversion. If the higher task blocks on the original task, it will boost its priority (even if it does the adaptive spin) which will again boost the task that it preempted. Now we may need to add a sched_yield() in the adaptive spin to let the other task run. -- Steve