On Tue, 9 May 2006, Lee Revell wrote:
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.
I don't understand why you want that. To me (which
knows about nothing about how the kernel works), the solution to
the problem is crystal clear: The softirq timer needs to have the highest
priority, and the only thing the sofirq timer threads does is to
make sure threads that should be woken up are put into some kernel
schedule queue somehow. I don't understand why the softirq timer threads
should cause any latency problems, what does it do except scheduling
waiting threads?
