On Fri, Apr 06, 2001 at 04:52:25PM -0700, Paul McKenney wrote:
> 1. On a busy system, isn't it possible for a preempted task
> to stay preempted for a -long- time, especially if there are
> lots of real-time tasks in the mix?
The problem you're describing is probably considered too hard to solve properly (bad answer,
but that is how it is currently)
Yes there is. You can also force a normal (non preemptive) kernel into complete livelock by
just giving it enough network traffic to do, so that it always works in the high priority
network softirq or doing the same with some other interrupt.
Just when this happens a lot of basic things will stop working (like page cleaning, IO
flushing etc.), so your callbacks or module unloads not running are probably the least
of your worries.
The same problem applies to a smaller scale to real time processes; kernel services
normally do not run real-time, so they can be starved.
Priority inversion is not handled in Linux kernel ATM BTW, there are already situations
where a realtime task can cause a deadlock with some lower priority system thread
(I believe there is at least one case of this known with realtime ntpd on 2.4)
> 2. Isn't it possible to get in trouble even on a UP if a task
> is preempted in a critical region? For example, suppose the
> preempting task does a synchronize_kernel()?
Ugly. I guess one way to solve it would be to readd the 2.2 scheduler taskqueue,
and just queue a scheduler callback in this case.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/