From: Con Kolivas <kernel@kolivas.org>
To: Robert Love <rml@tech9.net>, Ian Kumlien <pomac@vapor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [SHED] Questions.
Date: Mon, 1 Sep 2003 15:07:45 +1000 [thread overview]
Message-ID: <200309011507.45314.kernel@kolivas.org> (raw)
In-Reply-To: <1062389038.1313.39.camel@boobies.awol.org>
On Mon, 1 Sep 2003 14:03, Robert Love wrote:
> Look at it like this. Assume we have:
>
> Task A, B, and C at priority 10 (the highest)
> Task D at priority 5
> Tasks E and F at priority 0 (the lowest)
>
> We run them in that order: A, B, C, D, E, then F. And repeat.
> (Actually, within a given priority, the tasks are run round-robin in any
> nonspecific order.. effectively first-come, first-served scheduling).
>
> If [any task] has exhausted its timeslice, it will not run until the
> remaining tasks exhaust their timeslice. Once all tasks have expired,
> we start over.
I hate to keep butting in and saying this but this is not quite what happens.
If a task is considered interactive (a priority boost of 2 or more) and it
uses up a full timeslice then it is checked to see if a starvation limit has
been exceeded by the tasks on the expired array. If it hasn't exceeded the
limit, the interactive task will be rescheduled again ahead of everything
else. ie if A is the only task still considered interactive after using up
it's timeslice the first time it will go
A,B,C,A
before anything else
and if nothing else is interactive it can even go
A,B,C,A,A,A
etc until A is not considered interactive (boost lost) or the starvation limit
is exceeded.
This is not just with my patches; this is Ingo's design.
Con
next prev parent reply other threads:[~2003-09-01 5:00 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-31 10:07 [SHED] Questions Ian Kumlien
2003-08-31 10:17 ` Nick Piggin
2003-08-31 10:24 ` Ian Kumlien
2003-08-31 10:41 ` Nick Piggin
2003-08-31 10:46 ` Nick Piggin
[not found] ` <1062326980.9959.65.camel@big.pomac.com>
[not found] ` <3F51D4A4.4090501@cyberone.com.au>
2003-08-31 11:08 ` Ian Kumlien
2003-08-31 11:31 ` Nick Piggin
2003-08-31 11:43 ` Ian Kumlien
2003-08-31 18:53 ` Robert Love
2003-08-31 19:31 ` Ian Kumlien
2003-08-31 19:51 ` Robert Love
2003-08-31 22:41 ` Ian Kumlien
2003-08-31 23:41 ` Robert Love
2003-09-01 0:00 ` Ian Kumlien
2003-09-01 2:50 ` Con Kolivas
2003-09-01 15:58 ` Antonio Vargas
2003-09-01 22:19 ` Ian Kumlien
2003-09-01 4:03 ` Robert Love
2003-09-01 5:07 ` Con Kolivas [this message]
2003-09-01 5:55 ` Robert Love
2003-09-01 22:24 ` Ian Kumlien
2003-09-01 14:21 ` Antonio Vargas
2003-09-01 19:36 ` Geert Uytterhoeven
2003-09-01 22:49 ` Ian Kumlien
2003-09-01 15:07 ` Daniel Phillips
2003-09-01 14:16 ` Antonio Vargas
2003-09-01 23:03 ` Ian Kumlien
2003-09-02 0:04 ` Nick Piggin
2003-09-02 0:23 ` Con Kolivas
2003-09-02 10:25 ` Ian Kumlien
2003-09-02 11:08 ` Nick Piggin
2003-09-02 17:22 ` Ian Kumlien
2003-09-02 23:49 ` Nick Piggin
2003-09-03 23:02 ` Ian Kumlien
2003-09-04 1:39 ` Mike Fedyk
2003-09-02 10:44 ` Wes Janzen
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=200309011507.45314.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pomac@vapor.com \
--cc=rml@tech9.net \
/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).