Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753943AbcDTNLD (ORCPT ); Wed, 20 Apr 2016 09:11:03 -0400 Received: from merlin.infradead.org ([205.233.59.134]:38041 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753480AbcDTNLA (ORCPT ); Wed, 20 Apr 2016 09:11:00 -0400 Date: Wed, 20 Apr 2016 15:10:54 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: xlpang@redhat.com, linux-kernel@vger.kernel.org, Juri Lelli , Ingo Molnar , Steven Rostedt Subject: Re: [PATCH v3 1/6] rtmutex: Deboost before waking up the top waiter Message-ID: <20160420131054.GA3430@twins.programming.kicks-ass.net> References: <1460633827-345-1-git-send-email-xlpang@redhat.com> <1460633827-345-2-git-send-email-xlpang@redhat.com> <57149E8A.6060701@redhat.com> <20160420122011.GX3430@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1221 Lines: 32 On Wed, Apr 20, 2016 at 02:43:29PM +0200, Thomas Gleixner wrote: > > So its semantically icky to have the two tasks running off the same > > state and practically icky when you consider bandwidth inheritance -- > > where the boosted task wants to explicitly modify the state of the > > booster. > > > > In that latter case you really want to unboost before you let the > > booster run again. > > I understand that. That doesn't make the changelog any better, which mumbles > about priorities :( Agreed. > > However, you noted we need to deal with this case due to the whole > > optimistic spinning crap anyway :/ > > Right, but that's another dimension of madness. Both tasks are on a cpu. > The reason why we boost the lock holder before spinning is to make > sure that it does not get preempted by something of medium priority > before dropping the lock. Right; I figured that out pretty quickly, which is why this patch does a preempt_disable() over the unboost+wakeup. FWIW, the immediate reason for this patch is that is ensures the new p->pi_task pointer, points to something that exists. > That really gets interesting with bandwith inheritance .... I'm more worried about the optimistic spinning case..