From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753575AbaEDHSH (ORCPT ); Sun, 4 May 2014 03:18:07 -0400 Received: from casper.infradead.org ([85.118.1.10]:50933 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751360AbaEDHSG convert rfc822-to-8bit (ORCPT ); Sun, 4 May 2014 03:18:06 -0400 Date: Sun, 4 May 2014 09:17:58 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: Kirill Tkhai , "linux-kernel@vger.kernel.org" , Ingo Molnar , Steven Rostedt , Sebastian Andrzej Siewior , Paul Gortmaker Subject: Re: [RFC] rtmutex: Do not boost fair tasks each other Message-ID: <20140504071758.GK17778@laptop.programming.kicks-ass.net> References: <5362122B.8060305@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT 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 On Sat, May 03, 2014 at 08:54:08PM +0200, Thomas Gleixner wrote: > On Thu, 1 May 2014, Kirill Tkhai wrote: > > Higher priority does not provide exclusive privilege > > of one fair task over the other. In this case priority > > boosting looks excess. > > > > On RT patch with enabled PREEMPT_RT_FULL I see a lot of > > rt_mutex_setprio() actions like > > > > 120 -> 118 > > 118 -> 120 > > > > They harm RT tasks. > > That's not the main problem. The point is that it is useless and > therefor harming performace and throughput as well. > > > RT patch has lazy preemtion feature, so if idea is we care > > about excess preemption inside fair class, we should care > > about excess priority inheritance too. > > > > In case of vanila kernel the problem is the same, but there > > are no so many rt mutexes. Do I skip anything? > > Almost a decade ago we decided to do the boosting for everything > including SCHED_OTHER due to the very simple reason that exercising > that code path more is likely to trigger more bugs. > > But yes in a production environment, it's pointless for SCHED_OTHER > tasks. > > Though exercising that code path as much as we can is not a bad thing > either. So I'd like to see that made compile time conditional on one > of the lock testing CONFIG items. > > And the patch should be made against mainline, where we have the same > issue (reduced to PI-futexes). And of course, if we ever get to PEP, we very much want all the classes to participate :)