Re: realtime scheduling problems with 2.4 linux kernel >= 2.4.10
Andrea Arcangeli (email@example.com)
Fri, 31 May 2002 21:41:25 +0200
On Fri, May 31, 2002 at 11:28:47AM -0700, Mike Kravetz wrote:
> 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.
> > 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.
I tried it under uml on 2.4.19pre9aa2 and it worked fine there too.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/