On a "fair" scheduler these will all get high priority (and good
response) because their CPU bandwidth usage will be much smaller than
their entitlement and the scheduler will be trying to help them "catch
up". So (as you say) they shouldn't be a problem.
X's needs are more complex than that (from my observations) in that the
part of X that processes input doesn't use much CPU but the part that
does output can be quite a heavy user of CPU (e.g. do a "ls -lR /" in an
xterm and watch X chew up the CPU). At the same time, the part of X
that processes input needs quick responsiveness as it's part of the
interactive chain where this is less so for the output part.
Where X comes unstuck in the current scheduler is that when the output
part goes on one of its CPU storms it ceases to look like an interactive
task and gets given lower priority. Ironically, this doesn't effect the
output part of X but it does effect the input part and is manifest as
crappy interactive response. One wonders whether modifying X so that it
has two threads: one for output and one for input; that could be
scheduled separately might help. I guess it would depend on whether
there is insufficient independence between the two halves.
Part of this issue is that giving X a high static priority runs the risk
of the CPU hog output part disrupting scheduling of other important
tasks. So don't give it too big a boost.
It's worth noting that the -10 mentioned is roughly equivalent (in the
old scheduler) to restoring interactive task status to X in those cases
where it loses it due to a CPU storm in its output part.
I'd like to add the EBS scheduler (posted by Aurema Pty Ltd a couple of
years back) to this list as it also recommended running X at nice -5 to -10.
Also some of the "interactive bonus" mechanisms in my SPA schedulers
could be removed if X was reniced. In fact, with a reniced X the
spa_svr (server oriented scheduler which attempts to minimise the time
tasks spend on the queue waiting for CPU access and which doesn't have
interactive bonuses) might be usable on a work station.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
