Re: Xterm Hangs - Possible scheduler defect?

[Chad N. Tindel]

> > Hmmm... Are you suggesting it is OK for a kernel to get nearly completely
> > hosed and for not fully utilize all the processors in the system because
> > of one SCHED_FIFO thread?
> 
> Sure.  You specifically directed the scheduler to run your thread at a
> higher priority than anything else.  The way I see it, you used root's
> perogative to shoot himself in the foot.  You could also have used root's
> perogative to don steel toed shoes(set important kernel threads to a higher
> priority) before pulling the trigger.

No, I specifically directed the scheduler to run my thread at a higher 
priority than any other userspace application.  The fact that I wrote it 
in userspace and not in kernel space implies that I am OK with the kernel
stopping me sometimes when _it_ has work to do.  If I wanted something
higher priority than the kernel I would have written something in kernel
space instead.

>   SCHED_FIFO thread are supposed to preempt
> > all other userspace threads... not the kernel itself.
> 
> Not so.  The scheduler makes do distinction between user and kernel threads
> of execution.

That is SOOOO broken it isn't even funny.

> If you think that's broken, you'll _love_ Ingo's IRQ threads.  While testing
> one of his recent (slightly buggy)unpriveleged-user-does-RT patches in an
> IRQ threadified kernel, I ran a user SCHED_FIFO task at higher than the IRQ0
> thread... if my box had been an embeded washing machine controller instead
> of a desktop box, it'd have been a classic case of "No tickie no washie" :))

Yeah, thats broken too.

Perhaps I don't understand this philosophy you have where the kernel
isn't more important than everything else.  It seems to me like there needs
to be a rigid hierarchy for scheduling, lest you get into deadlock problems:

1.  Kernel preempts all.  There may be some hierarchy of kernel priorities
too, but it isn't important here.
2.  SCHED_FIFO processes preempt all userspace applications.
3.  SCHED_RR.
4.  SCHED_OTHER.

Under no circumstances should any single CPU-bound userspace thread completely 
hose a 64-way SMP box.

Can somebody educate me on why it is correct to do it any other way?

Chad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/