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
Received on Wed May 10 04:15:02 2006
This archive was generated by hypermail 2.1.8 : Wed May 10 2006 - 04:15:03 EEST