Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754740AbcDTMpF (ORCPT ); Wed, 20 Apr 2016 08:45:05 -0400 Received: from www.linutronix.de ([62.245.132.108]:44084 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751AbcDTMpD (ORCPT ); Wed, 20 Apr 2016 08:45:03 -0400 Date: Wed, 20 Apr 2016 14:43:29 +0200 (CEST) From: Thomas Gleixner To: Peter Zijlstra 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 In-Reply-To: <20160420122011.GX3430@twins.programming.kicks-ass.net> Message-ID: 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> 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: 1279 Lines: 32 On Wed, 20 Apr 2016, Peter Zijlstra wrote: > On Mon, Apr 18, 2016 at 11:02:28AM +0200, Thomas Gleixner wrote: > > On Mon, 18 Apr 2016, Xunlei Pang wrote: > > > 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. I understand that. That doesn't make the changelog any better, which mumbles about priorities :( > 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. That really gets interesting with bandwith inheritance .... Thanks, tglx