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

[Mike Kravetz]

On Sat, Jun 01, 2002 at 07:05:47PM +0200, Andi Kleen wrote:
> Mike Kravetz <[e-mail]> writes:
> 
> > 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.
> 
> One possibility is that something relies on schedule_task() - keventd
> doesn't run with realtime priority and can be starved.
> 
> Seems to be the case indeed: 
> 
> /usr/src/linux/drivers/char% grep schedule_task *.c
> console.c:      schedule_task(&console_callback_tq);
> ...
> 
> the console switch does.

Thanks Andi!

Part of the 'problem' is the following in the 'sched_setscheduler'
man page.

"      As  a  non-blocking  end-less  loop in a process scheduled
       under SCHED_FIFO or SCHED_RR will block all processes with
       lower priority forever, a software developer should always
       keep available on the console a shell  scheduled  under  a
       higher  static  priority than the tested application. This
       will allow an emergency kill of tested real-time  applica­
       tions  that  do  not  block  or  terminate as expected. As
       SCHED_FIFO and SCHED_RR processes can preempt  other  pro­
       cesses  forever,  only root processes are allowed to acti­
       vate these policies under Linux.
"

Seems that this tells people to leave a high priority real-
time shell running on the console.  However, if one can not
get to the console, then there is no point in leaving a high
priority shell running there.  Part of the problem may be
in the definition of 'console'.  Different console implementations
behave differently.

Is this something we should 'fix'?  I would envision a 'solution'
for each console implementation.  OR we could remove the above
from the man page. :)

Comments?
-- 
Mike