Date: Wed, 20 Apr 2016 14:20:11 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: xlpang@redhat.com, linux-kernel@vger.kernel.org,
        Juri Lelli <juri.lelli@arm.com>, Ingo Molnar <mingo@redhat.com>,
        Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v3 1/6] rtmutex: Deboost before waking up the top waiter
Message-ID: <20160420122011.GX3430@twins.programming.kicks-ass.net>
References: <1460633827-345-1-git-send-email-xlpang@redhat.com>
 <1460633827-345-2-git-send-email-xlpang@redhat.com>
 <alpine.DEB.2.11.1604181018080.3941@nanos>
 <57149E8A.6060701@redhat.com>
 <alpine.DEB.2.11.1604181059200.3941@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1604181059200.3941@nanos>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1230
Lines: 34

On Mon, Apr 18, 2016 at 11:02:28AM +0200, Thomas Gleixner wrote:
> On Mon, 18 Apr 2016, Xunlei Pang wrote:
> > On 2016/04/18 at 16:23, Thomas Gleixner wrote:
> > > On Thu, 14 Apr 2016, Xunlei Pang wrote:
> > >> We should deboost before waking the high-prio task such that
> > >> we don't run two tasks with the 'same' priority.
> > > No. This is fundamentaly broken.
> > >  
> > > T1 (prio 0)	lock(X)
> > >
> > > -->	 	preemption
> > >
> > > T2 (prio 10)	lock(X)
> > >    	 	boost(T1)
> > > 		schedule()
> > >
> > > T1 (prio 10)	unlock(X)
> > 
> > We add a preempt_disable() before deboost to avoid the breakage,
> > there's also some comment about this in the patch's code.
> 
> So the changelog is useless and misleading. Neither does it explain what's
> wrong with having two tasks with the same priority in running state.

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.

However, you noted we need to deal with this case due to the whole
optimistic spinning crap anyway :/