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:13:02 +1000 [thread overview]
Message-ID: <200308010113.02866.kernel@kolivas.org> (raw)
In-Reply-To: <58530000.1059663364@[10.10.2.4]>
On Fri, 1 Aug 2003 00:56, Martin J. Bligh wrote:
> --Con Kolivas <kernel@kolivas.org> wrote (on Thursday, July 31, 2003
01:28:49 +1000):
> > On Thu, 31 Jul 2003 01:01, Martin J. Bligh wrote:
> >> OK, so test2-mm1 fixes the panic I was seeing in test1-mm1.
> >> Only noticeable thing is that -mm tree is consistently a little slower
> >> at kernbench
> >
> > Could conceivably be my hacks throwing the cc cpu hogs onto the expired
> > array more frequently.
>
> Kernbench: (make -j vmlinux, maximal tasks)
> Elapsed System User CPU
> 2.6.0-test2 46.05 115.20 571.75 1491.25
> 2.6.0-test2-con 46.98 121.02 583.55 1498.75
> 2.6.0-test2-mm1 46.95 121.18 582.00 1497.50
>
> Good guess ;-)
>
> 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...
Con
next prev parent reply other threads:[~2003-07-31 15:09 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 [this message]
2003-07-31 15:19 ` Martin J. Bligh
2003-07-31 15:35 ` Con Kolivas
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=200308010113.02866.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;
as well as URLs for NNTP newsgroup(s).