Messages in this thread | | | Date | Fri, 31 May 2002 11:28:47 -0700 | From | Mike Kravetz <> | Subject | Re: realtime scheduling problems with 2.4 linux kernel >= 2.4.10 |
| |
On Thu, May 30, 2002 at 06:54:46PM +0100, Ian Collinson wrote: > > We're having problems with realtime scheduling (SCHED_RR and > SCHED_FIFO), on 2.4 kernels >= 2.4.10 (built for i386, no SMP). We have an > app that uses real-time scheduled threads. To aid debugging, in case of > realtime threads spinning and locking the system, we always keep a bash > running on a (text) console, at SCHED_RR, priority 99 (a higher priority > than any threads in our app). We test that this is a valid approach by > running a lower priority realtime app, on another console, that sits in an > infinite busy loop. This has always worked, and we've been able to > successfully use the high-priority bash to run gdb, and so on. This is also > what the man page for sched_setscheduler suggests, to avoid total system > lock up.
<snip>
> Then I switch back to the first console, with its priority 99 bash. > I am able to type away for 10 seconds, until the priority 50 process starts, > at which point the shell locks up. I can get the same effect on one > console with: > > > ( sleep 10; realtime -rr 50 eat_cpu ) & realtime -rr 99 bash > > Previously, the high-priority shell would never lock up. Now it > does.
This works fine for me on 2.4.17 with a SERIAL console. Could this be related to some differences (new features) in the VGA console? I am totally ignorant of how the consoles work.
-- Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |