Hi, Thomas,
have you seen this version?
Thanks,
Kirill
30.05.2014, 00:52, "Kirill Tkhai" <[email protected]>:
> ? ??, 28/05/2014 ? 22:26 +0200, Thomas Gleixner ?????:
>> ?On Mon, 5 May 2014, Kirill Tkhai wrote:
>>> ?? ??, 03/05/2014 ? 20:54 +0200, Thomas Gleixner ?????:
>>>> ?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.
>>> ?+#ifndef CONFIG_RT_MUTEX_BOOST_ALL
>> ?No, not another pointless config option. Read what I said. What's
>> ?wrong with using an existing config item, e.g DEBUG_RT_MUTEXES?
>>> ?+#define heritable_prio(prio) (rt_prio(prio) || dl_prio(prio))
>> ?inheritable please. It's not priority heritance and never will be.
>
> Thanks for comments. Here is new version.
>
> [PATCH] rtmutex: Do not boost owner's prio if waiter is SCHED_OTHER
>
> Higher priority does not provide exclusive privilege
> of one fair class task over the other. In this case
> priority boosting is pointless, and it may worsen
> performance.
>
> This patch makes boosting, which is requested by fair
> class waiters, optional. It's disabled by default, but
> it's possible to enable it for debugging purposes to
> have more cases of priority inheritance.
>
> Signed-off-by: Kirill Tkhai <[email protected]>
>
> ?kernel/locking/rtmutex.c | 28 +++++++++++++++++++++-------
> ?1 file changed, 21 insertions(+), 7 deletions(-)