From: Rob Landley <rob@landley.net>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] sched-2.6.0-test1-G6, interactivity changes
Date: Fri, 8 Aug 2003 15:41:52 -0400 [thread overview]
Message-ID: <200308081541.52569.rob@landley.net> (raw)
In-Reply-To: <200307290800.24003.kernel@kolivas.org>
On Monday 28 July 2003 18:00, Con Kolivas wrote:
> Agreed, and no doubt the smaller the timeslice the worse it is. I did a
> little experimenting with my P4 2.53 here and found that basically no
> matter how much longer the timeslice was there was continued benefit.
> However the benefit was diminishing the higher you got. If you graphed it
> out it was a nasty exponential curve up to 7ms and then there was a knee in
> the curve and it was virtually linear from that point on with only tiny
> improvements. A p3 933 behaved surprisingly similarly. That's why on
> 2.4.21-ck3 it was running with timeslice_granularity set to 10ms. However
> the round robin isn't as bad as pure timeslice limiting because if they're
> still on the active array I am led to believe there is less cache trashing.
>
> There was no answer in that but just thought I'd add what I know so far.
>
> Con
Fun.
Have you read the excellent DRAM series on ars technica?
http://www.arstechnica.com/paedia/r/ram_guide/ram_guide.part1-2.html
http://www.arstechnica.com/paedia/r/ram_guide/ram_guide.part2-1.html
http://www.arstechnica.com/paedia/r/ram_guide/ram_guide.part3-1.html
Sounds like you're thwacking into memory latency and bank switching and such.
(Yes, you can thrash dram. It's not as noticeable as with disk, but it's can
be done.)
The memory bus speed will affect this a little bit, but it's not going to do
to much for request turnaround time except make it proportionally even worse.
Same for DDR. :)
Rob
next prev parent reply other threads:[~2003-08-08 19:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-27 13:40 [patch] sched-2.6.0-test1-G6, interactivity changes Ingo Molnar
2003-07-27 14:03 ` Con Kolivas
2003-07-28 7:24 ` Ingo Molnar
2003-07-28 8:50 ` Con Kolivas
2003-07-28 21:38 ` Bill Davidsen
2003-07-28 22:00 ` Con Kolivas
2003-07-30 2:49 ` Bill Davidsen
2003-08-08 19:41 ` Rob Landley [this message]
2003-07-27 19:18 ` Felipe Alfaro Solana
2003-07-28 6:04 ` Mike Galbraith
2003-07-28 6:45 ` Andre Hedrick
2003-07-28 7:05 ` Con Kolivas
2003-07-28 7:33 ` Mike Galbraith
2003-07-28 7:44 ` Ingo Molnar
2003-07-30 14:24 ` Szonyi Calin
[not found] ` <Pine.LNX.4.44.0307280935300.4596-100000@localhost.localdom ain>
2003-07-28 8:15 ` Mike Galbraith
2003-07-28 8:42 ` Con Kolivas
2003-07-28 8:49 ` Mike Galbraith
[not found] ` <Pine.LNX.4.10.10307272338160.30891-100000@master.linux-ide .org>
2003-07-28 7:27 ` Mike Galbraith
2003-07-28 17:33 ` Andre Hedrick
[not found] ` <Pine.LNX.4.10.10307281030180.30891-100000@master.linux-ide .org>
2003-07-29 7:44 ` Mike Galbraith
2003-07-28 17:17 ` Jose Luis Domingo Lopez
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=200308081541.52569.rob@landley.net \
--to=rob@landley.net \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
/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).