Re: realtime scheduling problems with 2.4 linux kernel >= 2.4.10

[Andrea Arcangeli <andrea@suse.de>]

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.
> 
> <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.

I tried it under uml on 2.4.19pre9aa2 and it worked fine there too.

Andrea