public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: "Martin J. Bligh" <mbligh@aracnet.com>, Andrew Morton <akpm@osdl.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.0-test2-mm1 results
Date: Fri, 1 Aug 2003 01:35:57 +1000	[thread overview]
Message-ID: <200308010135.57514.kernel@kolivas.org> (raw)
In-Reply-To: <59900000.1059664740@[10.10.2.4]>

On Fri, 1 Aug 2003 01:19, Martin J. Bligh wrote:
> >> Does this help interactivity a lot, or was it just an experiment?
> >> Perhaps it could be less agressive or something?
> >
> > Well basically this is a side effect of selecting out the correct cpu
> > hogs in the interactivity estimator. It seems to be working ;-) The more
> > cpu hogs they are the lower dynamic priority (higher number) they get,
> > and the more likely they are to be removed from the active array if they
> > use up their full timeslice. The scheduler in it's current form costs
> > more to resurrect things from the expired array and restart them, and the
> > cpu hogs will have to wait till other less cpu hogging tasks run.
> >
> > How do we get around this? I'll be brave here and say I'm not sure we
> > need to, as cpu hogs have a knack of slowing things down for everyone,
> > and it is best not just for interactivity for this to happen, but for
> > fairness.
> >
> > I suspect a lot of people will have something to say on this one...
>
> Well, what you want to do is prioritise interactive tasks over cpu hogs.
> What *seems* to be happening is you're just switching between cpu hogs
> more ... that doesn't help anyone really. I don't have an easy answer
> for how to fix that, but it doesn't seem desireable to me - we need some
> better way of working out what's interactive, and what's not.

Indeed and now that I've thought about it some more, there are 2 other 
possible contributors

1. Tasks also round robin at 25ms. Ingo said he's not sure if that's too low, 
and it definitely drops throughput measurably but slightly.
A simple experiment is changing the timeslice granularity in sched.c and see 
if that fixes it to see if that's the cause.

2. Tasks waiting for 1 second are considered starved, so cpu hogs running with 
their full timeslice used up when something is waiting that long will be 
expired. That used to be 10 seconds.
Changing starvation limit will show if that contributes.

Con


  reply	other threads:[~2003-07-31 15:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-29 14:37 Panic on 2.6.0-test1-mm1 Martin J. Bligh
2003-07-29 21:18 ` Martin J. Bligh
2003-07-30 15:01   ` 2.6.0-test2-mm1 results Martin J. Bligh
2003-07-30 15:28     ` Con Kolivas
2003-07-30 16:27       ` Martin J. Bligh
2003-07-31 14:56       ` Martin J. Bligh
2003-07-31 15:13         ` Con Kolivas
2003-07-31 15:19           ` Martin J. Bligh
2003-07-31 15:35             ` Con Kolivas [this message]
2003-07-31 16:01               ` Martin J. Bligh
2003-07-31 16:11                 ` Con Kolivas
2003-07-31 21:19             ` William Lee Irwin III
2003-07-31 17:03           ` Bill Davidsen
2003-07-31 22:37 ` Panic on 2.6.0-test1-mm1 William Lee Irwin III
2003-07-31 22:41   ` William Lee Irwin III
2003-07-31 22:40     ` Andrew Morton
2003-08-01  0:15       ` William Lee Irwin III
2003-08-01  0:18         ` Zwane Mwaikambo
2003-08-01  0:20         ` William Lee Irwin III
2003-08-01  0:47   ` Martin J. Bligh
2003-08-01  0:53     ` William Lee Irwin III
2003-08-01  0:57       ` Martin J. Bligh
2003-08-01  1:02         ` William Lee Irwin III

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=200308010135.57514.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    /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