Messages in this thread | | | Date | Thu, 19 Dec 2002 16:02:34 -0800 | From | Andrew Morton <> | Subject | Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio |
| |
Robert Love wrote: > > On Thu, 2002-12-19 at 18:18, Andrew Morton wrote: > > > That is too often not the case. > > I knew you would say that! > > > I can get the desktop machine working about as comfortably > > as 2.4.19 with: > > > > # echo 10 > max_timeslice > > # echo 0 > prio_bonus_ratio > > > > ie: disabling all the fancy new scheduler features :( > > > > Dropping max_timeslice fixes the enormous stalls which happen > > when an interactive process gets incorrectly identified as a > > cpu hog. (OK, that's expected) > > Curious why you need to drop max_timeslice, too.
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 > apparent.
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 > 100ms.
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |