Re: Xterm Hangs - Possible scheduler defect?

[Chris Friesen]

Chad N. Tindel wrote:

> > I personally like the linux way: "root has the ability to shoot himself 
> > in the foot if he wants to". This is my computer, damn it, I am the one 
> > who tells it what to do.

> I'm all for allowing people to shoot themselves in the foot.  That doesn't
> mean that it is OK for a single userspace thread to mess up a 64-way box.

If root has explicitly stated that the thread in question is the highest 
priority thing on the entire machine, why would it not be okay.  The 
fact that root made a mistake is the issue here, not that the system 
didn't protect itself.

> > This is much, much better than the "users are stupid, we must protect 
> > them from themselves" kind of way that other OS'es use.

> Isn't this what the kernel attempts to do in many other places?  What else
> could possibly be the point of sending SIGSEGV and causing applications
> to dump core when they make a mistake referencing memory?  Isn't it the
> kernel's job to protect one application from another?

Yes.  But at the same time, if root wants to do something, the kernel 
should let them.  There are many, many ways that root could trash the 
system.  "cat /dev/urandom > /dev/kcore"  would do quite nicely.

> I see what you're saying about the swap daemon.  How about if I make my
> statement less black and white.  Some kernel threads should always have 
> priority over userspace.

Not necessarily.  The latest latency-reduction patches allow root to 
specify exactly what the priorities should be.

> I believe the mindset required for a home system that is doing audio recordings
> is different than the one for enterprise-level systems.  How do we unify
> the two?

There are professionals who use linux for audio as well, it's not just 
home systems.  That said, you unify them with reasonable defaults, and 
the ability for root to override them.

Chris

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