Messages in this thread | | | Subject | Re: low priority soft RT? | From | Benny Amorsen <> | Date | 27 Jul 1999 22:31:09 +0200 |
| |
>>>>> "RvR" == Rik van Riel <riel@humbolt.nl.linux.org> writes:
RvR> Sure. If you have a bunch of normal, interactive and niced RvR> processes, then a high-priority process can wait for over a RvR> second before a lock (held by a niced process) is released and RvR> the high-priority process can continue.
That's why I think that any process that holds a lock should have its priority boosted to just above all other SCHED_OTHER/SCHED_IDLE processes. This should be done not only for SCHED_IDLE processes but also for those with a policy of SCHED_OTHER.
RvR> Now, if we would follow Linus' idea and extend the range of niced RvR> processes, that time span could increase to 10 or even more RvR> seconds, effectively producing the same kind of 'deadlock' that RvR> SCHED_IDLE can produce -- only with an upper bound to it...
RvR> Then throw in SCHED_RR or SCHED_FIFO processes and you're gone.
It's ok that SCHED_RR or SCHED_FIFO processes can kill the system. They have to be root to do it, and it doesn't surprise anyone. As long as SCHED_IDLE is available to root only, it's somewhat ok for it to be able to kill the system. It's surprising though, and that is bad.
It is not ok for SCHED_OTHER processes to be able to penalize other processes unfairly. That really should be fixed.
Benny
- 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/
| |