Yep, as Mike mentioned, renicing X causes it to get bigger
timeslices with the stock scheduler. If you had 2 nice -20 processes,
they would each get a timeslice of 200ms, so you're harming their
latency.
Well, if I can be naive for a second (and I'll fully admit I don't
understand the implications of this), there are two things here - either give it more of a timeslice (bandwidth increase), or make it more interactive (latency increase). Those two seem to be separable,
but we don't bother. Seems better to pass a more subtle hint to the
scheduler that this is interactive - nice seems like a very large
brick between the eyes.
There may be some more details around this, and I'd love to hear them,Well it would be nice if someone could find out how to do it, but I
but I fundmantally believe that explitit fiddling with particular
processes because we believe they're somehow magic is wrong (and so
does Linus, from previous discussions).
think that if we want X to be able to get 80% CPU when 2 other CPU hogs
are running, you have to renice it.
OK. So you renice it ... then your two cpu jobs exit, and you kick off
xmms. Every time you waggle a window, X will steal the cpu back from
xmms, and it'll stall, surely? That's what seemed to happen before.
I don't see how you can fix anything by doing static priority alterations
(eg nice), because the workload changes.
I'm probably missing something ... feel free to slap me ;-)