On Tue, 2006-05-09 at 13:27 -0700, Kjetil S. Matheussen wrote:
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.
Hmm, it sounds like a solution could be to separate timers that just
wake up a process from ones that do actual work and run them in separate
kernel threads.
Lee