I think the two will always related. One means giving a higher
dynamic priority, the other a bigger timeslice. So you want
say gcc to have a 100ms timeslice with lowest scheduling prio,
but X to have a 20ms slice and a very high scheduling priority.
Right.
Unfortunately, the way the scheduler currently works, X might
use all its timeslice, then have to wait 100ms for gcc to finish
its. The way I do it is give a small timeslice to high prio tasks,
and lower priority tasks get progressively less.
If the interactive task uses all it's timeslice, then it's not really
very interactive, it's chewing quite a bit of CPU ... presumably in
the common case, these things don't finish their timeslices. I thought
we preempted the running task when a higher prio one woke up, so this
should still work, right?
So it would seem to make sense to boost the prio of a interactive task *without* increasing the size of it's timeslice.
When _only_ low priority tasks are running, they'll all get long
timeslices.
That at least makes sense. AFIAK at least the early versions of Con's
stuff make cpu bound jobs' timeslices short even if there were no
interactive jobs. I don't like that (or more relevantly, the benchmarks
don't either ;-)).
OK well just as a rough idea of how mine works: worst case for
xmms is that X is at its highest dynamic priority (and reniced).
xmms will be at its highest dynamic prio, or maybe one or two
below that.
X will get to run for maybe 30ms first, then xmms is allowed 6ms.
That is still 15% CPU. And X soon comes down in priority if it
continues to use a lot of CPU.
If it works in practice, it works, I guess. I just don't see why X
is super special ... are we going to have to renice *all* interactive tasks in order to get things to work properly?