Messages in this thread | | | Date | Sun, 4 May 2014 14:13:13 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [RFC] rtmutex: Do not boost fair tasks each other |
| |
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 :)
| |