[lkml]   [2006]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: New PriorityInheritanceTest - bug in 2.6.17-rt7 confirmed
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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-07-06 15:17    [W:0.053 / U:11.692 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site