There's a distinction between giving it more cpu and giving it higher
priority: the important part about having high priority is getting low
latency access to the cpu when its needed.
This really seems like the wrong approach to me. The implication here
and in other mails is that fairness is an inherently good thing which
should obviously take preference over any other property.
It's a nice simple stance, and its relatively easy to code up and test
to see that its working, but it doesn't really give people what they want.
The old unix-style dynamic priority scheme was designed to give
interactive processes high priorities, by using the observation that
"interactive" means "spends a lot of time blocked waiting for input".
That model of interactive is way too simple now, and the attempts to try
an find an equivalent heuristic have been flawed and lead to - in some
cases - wildly bad behaviours. I'm guessing the emphasis on "fairness"
is in reaction to this, which is fair enough.
But saying that the user needs to explicitly hold the schedulers hand
and nice everything to tell it how to schedule seems to be an abdication
of duty, an admission of failure. We can't expect users to finesse all
their processes with nice, and it would be a bad user interface to ask
them to do so.
And if someone/distro *does* go to all the effort of managing how to get
all the processes at the right nice levels, you have this big legacy
problem where you're now stuck keeping all those nice values meaningful
as you continue to develop the scheduler. Its bad enough to make them
do the work in the first place, but its worse if they need to make it a
kernel version dependent function.
J
-
