Re: New PriorityInheritanceTest - bug in 2.6.17-rt7 confirmed

[Esben Nielsen]

On Thu, 6 Jul 2006, Esben Nielsen wrote:

> On Thu, 6 Jul 2006, Ingo Molnar wrote:
>
> >  * Esben Nielsen <nielsen.esben@xxxxxxxxxxxxxx> wrote:
> >
> > >  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".
> >
> >  we could just queue the task in front of the other task in the runqueue,
> >  and mark that task for reschedule if it's running currently. (Doing this
> >  is not without precedent: we do something similar in wake_up_new_task()
> >  to implement child-runs-first logic.)
> I think that is more or less what my patch does...
I was a little bit in a hurry when I sent that comment:

What my patch does is to ensure rtmutex-boosters keep their priority and 
is scheduled to the head of the runqueue at their given priority.
What is ugly is that the scheduler core code knows about the rtmutex stuff 
directly. The previous mail was about how to generalise this so that other 
subsystems with similar needs can use it too.

Esben


> Esben
>
> >   Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/