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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
