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
