lkml.org 
[lkml]   [1999]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: low priority soft RT?
From
Date
>>>>> "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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.175 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site