> > Sure. If you have a bunch of normal, interactive and niced
> > processes, then a high-priority process can wait for over a
> > second before a lock (held by a niced process) is released
> > and the high-priority process can continue.
> >
> > Now, if we would follow Linus' idea and extend the range
> > of niced processes, that time span could increase to 10 or
> > even more seconds, effectively producing the same kind of
> > 'deadlock' that SCHED_IDLE can produce -- only with an upper
> > bound to it...
>
> I'm one of those old fashioned people who thinks that a deadlock
> with an upper bound is much better than one without.
Yes, but if you extended your range, you would have "deadlock with
upperbound of minute" situation, which is very bad, also.
> > Then throw in SCHED_RR or SCHED_FIFO processes and you're
> > gone.
>
> But SCHED_RR is a problem on its own, is it not?
>
> setsched(SCHED_RR)
> while(i < 100 ){
> g = g+1;
> /* oops, I forgot to increment i*/
> }
>
> And inetd never runs again.
No. There's currently trick to disable high-priority rt process using
one normal process grabbing lock and one low-priority rt process
eating all cpu time. Not good, also.
Pavel
-- I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature, please!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/