Re: Xterm Hangs - Possible scheduler defect?

[Ingo Oeser <ioe-lkml@axxeo.de>]

Chad N. Tindel wrote:
> I think what we have are the need for two levels of applications:
>
> 1.  That which wishes to be the highest priority userspace application, and
> wishes to preempt all other userspace applications.  Such an application is
> OK being preempted by the kernel when the kernel needs to do work.  IMHO,
> this should be the default behavior for any SCHED_FIFO application.  If one
> of these has a bug and goes CPU-bound, the worst it can do is prevent other
> apps from ever using the CPU it is on.

That is basically, what you do with SCHED_RR.
(Be preempted after maximum quantum, even if having work to do)

> 2.  Applications which actually want to be the highest priority thing on
> the system, including being higher than the kernel.  These applications are
> OK with the fact that they may cause system hangs and deadlocks, and are
> careful not to shoot themselves in the foot.

This is SCHED_FIFO.
(Strict priority scheduling, allowed to starve anything below)

So just try to use the right scheduler for your application right now, ok?

If your system is busy with top priority task, why should the kernel disturb 
it?

Things will stop anyway, if your high priority task is needing a resource,
which is blocked. Than it becomes unrunnable and other tasks have
chances to continue. Kernel threads are likely to execute then, because they
are likely runnable then. Your task could even migrate, if a lot of kernel 
tasks 
are waiting in one CPU and your task is NOT bound to a specific CPU.

So the system is not brought down, but just busy in a infortunate way.
Stupid applications can starve other applications for a while, but not
forever, because the kernel is still running and deciding.


Regards

Ingo Oeser