From: Nick Piggin <piggin@cyberone.com.au>
To: bill davidsen <davidsen@tmr.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: scheduler interactivity: timeslice calculation seem wrong
Date: Wed, 20 Aug 2003 12:52:37 +1000 [thread overview]
Message-ID: <3F42E275.5010005@cyberone.com.au> (raw)
In-Reply-To: <bhts76$8bm$1@gatekeeper.tmr.com>
bill davidsen wrote:
>In article <3F41B43D.6000706@cyberone.com.au>,
>Nick Piggin <piggin@cyberone.com.au> wrote:
>| Eric St-Laurent wrote:
>
>| >
>| >Anyway i always tought linux default timeslice of 100 ms is way too long
>| >for desktop uses. Starting with this in mind, i think that a 10 ms
>| >timeslice should bring back good interactive feel, and by using longer
>| >timeslices for (lower prio) cpu-bound processes, we can save some costly
>| >context switches.
>| >
>|
>| I agree completely.
>|
>| >
>| >Unfortunatly i'm unable to test those ideas right now but i share them,
>| >maybe it can help other's work.
>| >
>| >- (previously mentionned) higher prio tasks should use small timeslices
>| >and lower prio tasks, longer ones. i think, maybe falsely, that this can
>| >lower context switch rate for cpu-bound tasks. by using up to 200 ms
>| >slices instead of 10 ms...
>| >
>| >- (previously mentionned) use dynamic priority to calculate timeslice
>| >length.
>| >
>| >- maybe adjust the max timeslice length depending on how many tasks are
>| >running/ready.
>| >
>|
>| I agree with your previous two points. Not this one. I think it is very
>| easy to get bad feedback loops and difficult to ensure it doesn't break
>| down under load when doing stuff like this. I might be wrong though.
>
>I have to agree with Eric that sizing the max timeslices to fit the
>hardware seems like a reasonable thing to do. I have little salvaged
>systems running (well strolling would be more accurate) Linux on old
>Pentium Classic 90-166MHz machines. I also have 3+ GHz SMP machines. I
>have a gut feeling that the timeslices need to be longer on the slow
>machines to allow them to get something done, that the SMP machines
>will perform best with a different timeslice than UP of the same speed,
>etc.
>
Well its just so hard to get right. If someone could demonstrate a
big performance improvement, then the scheduler might need fixing
anyway.
For example, on your machines, its very likely that your new machines
would benefit more from big timeslices than the old ones due to more
cache, quicker cpu to memory, multiple cpus...
next prev parent reply other threads:[~2003-08-20 2:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-19 2:54 scheduler interactivity: timeslice calculation seem wrong Eric St-Laurent
2003-08-19 3:06 ` Nick Piggin
2003-08-19 4:07 ` Eric St-Laurent
2003-08-19 5:23 ` Nick Piggin
2003-08-19 6:54 ` Eric St-Laurent
2003-08-19 19:18 ` bill davidsen
2003-08-19 23:48 ` Eric St-Laurent
2003-08-19 23:54 ` Eric St-Laurent
2003-08-19 19:01 ` bill davidsen
2003-08-20 0:15 ` Eric St-Laurent
2003-08-20 0:32 ` David Lang
2003-08-20 0:48 ` William Lee Irwin III
2003-08-20 4:11 ` Bill Davidsen
2003-08-20 4:36 ` William Lee Irwin III
2003-08-20 13:59 ` Andrew Theurer
2003-08-20 16:18 ` Bill Davidsen
2003-08-20 2:52 ` Nick Piggin [this message]
2003-08-19 19:02 ` Mike Fedyk
2003-08-19 17:51 ` Mike Fedyk
2003-08-20 2:41 ` Nick Piggin
2003-08-20 18:45 ` Mike Fedyk
2003-08-19 4:13 ` Con Kolivas
2003-08-19 4:23 ` Eric St-Laurent
2003-08-19 4:29 ` Con Kolivas
2003-08-19 5:06 ` Eric St-Laurent
2003-08-19 6:18 ` 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=3F42E275.5010005@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=davidsen@tmr.com \
--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