Re: New PriorityInheritanceTest - bug in 2.6.17-rt7 confirmed

[Esben Nielsen <nielsen.esben@googlemail.com>]

On Thu, 6 Jul 2006, Thomas Gleixner wrote:

> On Thu, 2006-07-06 at 14:07 +0100, Esben Nielsen wrote:
>> So this is a real bug.
>
> True
>
>> In the previous mail I posted a fix for that problem (and other problems).
>
> I had not much time to look at the patch, but I doubt that we need such
> a complex hack to achieve that. I will look at it later.

The problem is that the deboosting code have to run somewhere.
It can run within try_to_wake_up(). But then it the whole lock chain is 
traversed in an atomic section. That unpredictable overall system 
latencies since the locks can be in userspace.
So it has to run in some task. That task has to be high priority enough 
to preempt the boosted tasks, but it can't be so high priority that it bothers
any higher priority threads than those involved in this. So it can't be, 
forinstance a general priority 99 task we just use for this. We thus need 
something running at a slightly higher priority than the priority to 
which the tasks are boosted, but not a full +1 priority. I.e. we need to 
run it at priority "+0.5".

I also think that other stuff, like high resolution timers and others 
doing "scheduler plumbing work" in the kernel could benifit from a +0.5 
priority.

I thought about some improvements:
1) Make a general TSK_LIFO flag, That would remove some of the direct 
references in sched.c to the rtmutex system. In effect it will be the 
same, but be more usefull to other subsystems.
2) Double the number of in-kernel priorities. I.e. simply add a number of 
"hidden" priorities in which this kind of "plumbing" work can be run:

Kernel priority          User space
      0                      hidden
      1                        RT 99
      2                      hidden
      3                        RT 98
....

    199                         0
...

This might turn out more clean than a TSK_LIFO. There will be no need to
hack the core scheduler code, which can have some strange side-effect. 
But to be honest I don't think the hacks I have done are that bad - except
they refer directly to the rtmutex subsystem. Also adding priorities would
slow down the system.


>
> 	tglx
>
>

Esben