Just so you know the context, I'm coming at this from the point of view
of an embedded call server designer.
Mark Hahn wrote:
Fairness is good because it promotes predictability. See the
"deterministic" section below.
If you have nice 19 be sufficiently low priority, then the difference
between "using cpu if otherwise idle" and "gets a little bit of cpu even
if not totally idle" is unimportant.
Starvation is a very *bad* thing when you don't want it.
In my environment, latency *matters*. If a packet doesn't get processed
in time, you drop it. With mainline it can be quite tricky to tune the
latency, especially when you don't want to resort to soft realtime
because you don't entirely trust the code thats running (because it came
from a third party vendor).
Determinism is really important. It almost doesn't matter what the
behaviour is, as long as we can predict it. We model the system to
determine how to tweak the system (niceness, sched policy, etc.), as
well as what performance numbers we can advertise. If the system is
non-deterministic, it makes this modelling extremely difficult--you end
up having to give up significant performance due to worst-case spikes.
If the system is deterministic, it makes it much easier to predict its
actions.
Chris
-
