On Tue, 9 May 2006, Lee Revell wrote:
On Tue, 2006-05-09 at 12:56 -0700, Kjetil S. Matheussen wrote:
Then theres a latency problem in the kernel. A sleeping high priorioty
SCHED_FIFO thread must be woken up in time even if another lower
priority SCHED_FIFO thread is buzy-looping. And currently, unless the
softirq timer has priority 99, that condition can not be fullfilled.
So, the softirq timer must run with priority 99.
I think it's unusual to want a high priority SCHED_FIFO thread to be
awakened by a timer. What are you trying to do?
Well, the reason for stumble upon this problem is when I ported/tested
the general watchdog program "das_watchdog" from 2.4 to 2.6. For some
reason, it just didn't work. But after reading the instructions for
Florians rt_watchdog program, it became clear that the softirq
thread must have priority 99.
But lets say that you have program with two SCHED_FIFO threads. One
of them is a high priority (between 2 and 98) timer that is only
used to signal other threads. The other SCHED_FIFO thread has priority
1 and needs to run realtime for some reason, and it might not even be
a good reason. However, if that other thread have to do
some hard work, it stalls your high priority timer thread for a small
time, and your sleep-based timer suddenly becomes shaky.
I don't know any real-world examples of this, but I don't find it
unlikely to already happen, because its not always obviously noticable.
For example, that cpu-hogging thread can very well be a jack client
like jamin, and that timer process might very well be muse or
rosegarden. And for all we know, the scenario drawn up above, can
be already be relevant for a large percentage of all linux audio users,
its just not obviously noticable.
