Messages in this thread | | | Date | Sun, 4 May 2014 09:17:58 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC] rtmutex: Do not boost fair tasks each other |
| |
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 :)
| |