On Sun, 4 May 2014, Peter Zijlstra wrote: > 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 :)
That's true. We deal with it when it arrives :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
