From: Andrew Morton <akpm@digeo.com>
To: Robert Love <rml@tech9.net>
Cc: Con Kolivas <conman@kolivas.net>,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
Date: Thu, 19 Dec 2002 16:02:34 -0800 [thread overview]
Message-ID: <3E025E1A.EA32918A@digeo.com> (raw)
In-Reply-To: 1040341293.2521.71.camel@phantasy
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.
next prev parent reply other threads:[~2002-12-19 23:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-19 21:50 [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio Con Kolivas
2002-12-19 22:46 ` Robert Love
2002-12-19 23:18 ` Andrew Morton
2002-12-19 23:41 ` Robert Love
2002-12-20 0:02 ` Andrew Morton [this message]
2002-12-20 0:15 ` Robert Love
2002-12-20 0:22 ` Con Kolivas
2002-12-20 0:29 ` Robert Love
2002-12-20 0:27 ` Andrew Morton
2002-12-20 2:42 ` Robert Love
2002-12-20 2:48 ` Andrew Morton
2002-12-24 22:26 ` scott thomason
2002-12-25 7:29 ` Con Kolivas
2002-12-25 16:17 ` scott thomason
2002-12-26 15:01 ` scott thomason
2003-01-01 0:31 ` Impact of scheduler tunables on interactive response (was Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio) scott thomason
2003-01-01 16:05 ` Bill Davidsen
2003-01-01 17:15 ` scott thomason
2002-12-19 23:42 ` [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio Con Kolivas
2002-12-19 23:53 ` Robert Love
2002-12-20 0:04 ` Con Kolivas
2002-12-20 0:16 ` Robert Love
2002-12-20 11:17 ` Marc-Christian Petersen
2002-12-20 17:54 ` Robert Love
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E025E1A.EA32918A@digeo.com \
--to=akpm@digeo.com \
--cc=conman@kolivas.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@tech9.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox