All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.