What Con said. When the scheduler makes an inappropriate decision,
shortening the timeslice minimises its impact.
> Did you do that _before_ changing the interactivity estimator?
I disabled the estimator first. The result was amazingly bad ;)
> Dropping max_timeslice
> closer to min_timeslice would do away with a lot of effect of the
> interactivity estimator, since bonuses and penalties would be less
Yup. One good test is to keep rebuilding a kernel all the time,
then just *use* the system. Setting max_timeslice=10, prio_bonus=10
works better still. prio_bonus=25 has small-but-odd lags.
> There would still be (a) the improved priority given to interactive
> processes and (b) the reinsertion into the active away done to
> interactive processes.
> Setting prio_bonus_ratio to zero would finish off (a) and (b). It would
> also accomplish the effect of setting max_timeslice low, without
> actually doing it.
> Thus, can you try putting max_timeslice back to 300? You would never
> actually use that range, mind you, except for niced/real-time
> processes. But at least then the default timeslice would be a saner
prio_bonus=0, max_timeslice=300 is awful. Try it...
> But that in no way precludes not fixing what we have, because good
> algorithms should not require tuning for common cases. Period.
hm. Good luck ;)
This is a situation in which one is prepares to throw away some cycles
to achieve a desired effect.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/