From: Jamie Lokier <jamie@shareable.org>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: Piet Delaney <piet@www.piet.net>,
George Anzinger <george@mvista.com>,
Clayton Weaver <cgweav@email.com>,
linux-kernel@vger.kernel.org
Subject: Re: Circular Convolution scheduler
Date: Tue, 14 Oct 2003 11:18:53 +0100 [thread overview]
Message-ID: <20031014101853.GA28905@mail.shareable.org> (raw)
In-Reply-To: <3F8BCAB3.2070609@cyberone.com.au>
Nick Piggin wrote:
> I don't know anything about it, but I don't see what exactly you'd be
> trying to predict: the kernel's scheduler _dictates_ scheduling behaviour,
> obviously. Also, "best use of system resources" wrt scheduling is a big
> ask considering there isn't one ideal scheduling pattern for all but the
> most trivial loads, even on a single processor computer (fairness, latency,
> priority, thoughput, etc). Its difficult to even say one pattern is better
> than another.
Hmm. Prediction is potentially useful.
Instead of an educated ad-hoc pile of heuristics for _dictating_
scheduling behaviour, you can systematically analyse just what is it
you're trying to achieve, and design a behaviour which achieves that
as closely as possible.
This is where good predictors come in: you feed all the possible
scheduling decisions at any point in time into the predictor, and use
the output to decide which decision gave the most desired result -
taking into account the likelihood of future behaviours. Of course
you have to optimise this calculation.
This is classical control theory. In practice it comes up with
something like what we have already :) But the design path is
different, and if you're very thoroughly analytical about it, maybe
there's a chance of avoiding weird corner behaviours that weren't
intended.
The down side is that crafted heuristics, like the ones we have, tend
to run a _lot_ faster.
-- Jamie
next prev parent reply other threads:[~2003-10-14 10:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-06 16:17 Circular Convolution scheduler Clayton Weaver
2003-10-07 22:19 ` George Anzinger
2003-10-14 8:37 ` Piet Delaney
2003-10-14 9:46 ` Jamie Lokier
2003-10-14 10:06 ` Nick Piggin
2003-10-14 10:18 ` Jamie Lokier [this message]
2003-10-14 10:28 ` Nick Piggin
2003-10-16 8:34 ` Piet Delaney
2003-10-16 9:03 ` Nick Piggin
2003-10-21 18:09 ` bill davidsen
-- strict thread matches above, loose matches on Subject: below --
2003-10-07 20:47 Clayton Weaver
2003-10-16 1:51 Clayton Weaver
2003-10-21 18:44 ` bill davidsen
2003-10-21 20:15 ` Richard B. Johnson
2003-10-21 20:54 ` bill davidsen
2003-10-19 8:50 Clayton Weaver
2003-10-21 18:51 ` bill davidsen
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=20031014101853.GA28905@mail.shareable.org \
--to=jamie@shareable.org \
--cc=cgweav@email.com \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=piet@www.piet.net \
--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