On Sat, Jun 01, 2002 at 07:05:47PM +0200, Andi Kleen wrote:
> Mike Kravetz <kravetz@us.ibm.com> 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 - 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/
This archive was generated by hypermail 2b29 : Fri Jun 07 2002 - 22:00:16 EST