From: Con Kolivas <kernel@kolivas.org>
To: David Lang <david.lang@digitalinsight.com>
Cc: John Yau <jyau_kernel_dev@hotmail.com>,
Nick Piggin <piggin@cyberone.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Minor scheduler fix to get rid of skipping in xmms
Date: Mon, 8 Sep 2003 10:47:45 +1000 [thread overview]
Message-ID: <200309081047.45461.kernel@kolivas.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0309071722430.20816-100000@dlang.diginsite.com>
On Mon, 8 Sep 2003 10:27, David Lang wrote:
> On Mon, 8 Sep 2003, Con Kolivas wrote:
> > Ultra short timeslices would dissolve a lot of the interactivity issues
> > but come with a serious problem - most cpu caches these days, which are
> > incredibly valuable to cpu performance, take time to be filled and
> > emptied, and 1ms timeslices are just too short to use their benefits. The
> > time required to derive useful benefit depends on the cpu type but can be
> > up to 20ms. In my patches, the most interactive tasks round robin every
> > 10ms which can cause some detriment to performance, but fortunately
> > interactive tasks tend not to be as cpu bound as other tasks. What also
> > happens is that if an interactive task decides to use a burst of cpu it
> > will always be dropped by at least one priority so the tasks that only
> > ever use small amounts of cpu (read audio apps) will always go first.
>
> Con,
> doesn't this get affected more with the CPU and memory speed then with
> clock time? (i.e. the faster CPU is calling for addresses in a sorter time
> period since it gets through more of the program and the faster memory
> gets the cache misses into cache faster)
>
> or are the caches getting enough larger as CPU and memeory
> speeds climb that the clock time is close to being consistant?
>
> it just seems wrong to list a specific wall clock time nessasary to fill a
> cache with so many variables, it may have been correct as of the date that
> time was calculated, but as CPU's change I would expect the minimum time
> to vary quite a bit based on the particular CPU (which brings up the
> question of if the timeslices should be different for different CPU's)
Good question. What it seems from basic testing is that the cache build
up/tear down time does not seem to change at the same rate as the clock speed
at all. From the testing I _could_ do, it made no difference across PII->PIV
in terms of deriving benefit from the minimum timeslice possible, suggesting
to me that the cache is probably the rate limiting thing but I have no
further science to back me up on that. This meant to me that despite the fact
that varying timeslice according to clock speed sounding like a good idea, it
would probably be better to vary the timeslice according to cpu architecture
first (i386), family second (P2 versus P4), and clock speed to not have any
effect. All in all it makes for another swag of confusing changes that
probably are not worth it in the grand scheme if the baseline settings work
well across the board.
There are heaps of people out there with more hardware knowledge than I who
could answer this better.
Con
next prev parent reply other threads:[~2003-09-08 0:40 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-06 9:46 [PATCH] Minor scheduler fix to get rid of skipping in xmms John Yau
2003-09-06 10:03 ` Michael Buesch
2003-09-06 17:01 ` Robert Love
2003-09-06 17:59 ` John Yau
2003-09-06 18:17 ` John Yau
2003-09-06 19:42 ` Rahul Karnik
2003-09-06 20:04 ` Robert Love
2003-09-06 22:41 ` John Yau
2003-09-07 2:40 ` Martin J. Bligh
2003-09-07 5:13 ` Nick Piggin
2003-09-07 7:48 ` Johnny Yau
2003-09-07 8:10 ` Nick Piggin
2003-09-07 8:35 ` John Yau
2003-09-07 9:26 ` Nick Piggin
2003-09-07 17:30 ` John Yau
2003-09-07 17:36 ` Nick Piggin
2003-09-08 0:22 ` Con Kolivas
2003-09-08 0:27 ` David Lang
2003-09-08 0:47 ` Con Kolivas [this message]
2003-09-07 5:08 ` Nick Piggin
2003-09-07 6:18 ` Andrew Morton
2003-09-07 6:29 ` Nick Piggin
2003-09-07 6:45 ` Andrew Morton
2003-09-07 6:59 ` Nick Piggin
2003-09-07 7:02 ` Nick Piggin
2003-09-07 14:32 ` Martin J. Bligh
2003-09-07 17:02 ` Robert Love
2003-09-07 17:34 ` Andrew Morton
2003-09-07 18:12 ` Nick Piggin
2003-09-07 18:13 ` Nick Piggin
2003-09-06 15:58 John Yau
2003-09-06 16:57 ` Michael Buesch
2003-09-08 22:27 Steven Pratt
2003-09-08 22:56 ` Andrew Morton
2003-09-08 23:22 ` William Lee Irwin III
2003-09-09 2:10 ` Con Kolivas
2003-09-09 2:16 ` Con Kolivas
2003-09-09 2:31 ` Con Kolivas
2003-09-09 2:33 ` Andrew Morton
2003-09-09 4:14 ` Nick Piggin
2003-09-09 6:49 ` Con Kolivas
2003-09-09 23:53 ` Cliff White
2003-09-10 2:12 ` Nick Piggin
2003-09-10 19:05 ` Steven Pratt
2003-09-10 20:23 ` Dave Hansen
[not found] ` <3F5FE385.10204@cyberone.com.au>
[not found] ` <3F607E62.3010903@austin.ibm.com>
[not found] ` <3F60873B.4000005@cyberone.com.au>
2003-09-11 22:57 ` Steven Pratt
2003-09-11 0:14 ` Cliff White
2003-09-09 22:06 ` Steven Pratt
2003-09-09 22:12 ` Andrew Morton
2003-09-10 13:59 ` Steven Pratt
2003-09-10 18:51 ` Steven Pratt
[not found] <tCPY.4xU.1@gated-at.bofh.it>
[not found] ` <tDsR.5tY.31@gated-at.bofh.it>
[not found] ` <tZ0f.49P.5@gated-at.bofh.it>
[not found] ` <tZjz.4Bn.7@gated-at.bofh.it>
2003-09-09 23:24 ` David Mosberger-Tang
2003-09-11 2:55 Andrew Theurer
2003-09-11 11:04 ` Nick Piggin
2003-09-11 13:05 ` Andrew Theurer
2003-09-11 13:53 ` Nick Piggin
2003-09-11 14:37 ` Andrew Theurer
2003-09-11 23:32 Craig Thomas
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=200309081047.45461.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=david.lang@digitalinsight.com \
--cc=jyau_kernel_dev@hotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
/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).