From: Al Boldi <a1426z@gawab.com>
To: Con Kolivas <kernel@kolivas.org>
Cc: ck list <ck@vds.kolivas.org>, linux-kernel@vger.kernel.org
Subject: Re: was Re: quell interactive feeding frenzy
Date: Sun, 16 Apr 2006 22:03:31 +0300 [thread overview]
Message-ID: <200604162203.32193.a1426z@gawab.com> (raw)
In-Reply-To: <200604162037.02044.kernel@kolivas.org>
Con Kolivas wrote:
> Al Since you have an unhealthy interest in cpu schedulers you may also
> want to look at my ultimate fairness with mild interactivity builtin cpu
> scheduler I hacked on briefly. I was bored for a couple of days and came
> up with the design and hacked it together. I never got around to finishing
> it to live up fully to its design intent but it's working embarassingly
> well at the moment. It makes no effort to optimise for interactivity in
> anyw way. Maybe if I ever find some spare time I'll give it more polish
> and port it to plugsched. Ignore the lovely name I give it; the patch is
> for 2.6.16. It's a dual priority array rr scheduler that iterates over all
> priorities. This is as opposed to staircase which is a single priority
> array scheduler where the tasks themselves iterate over all priorities.
It's not bad, but it seems to allow cpu-hogs to steal left-over timeslices,
which increases unfairness as the proc load increases. Conditionalizing
prio-boosting based on hogginess maybe one way to compensate for this. This
would involve resisting any prio-change unless hogged, which should be
scaled by hogginess, something like SleepAVG but much simpler and less
fluctuating.
Really, the key to a successful scheduler would be to build it step by step
by way of abstraction, modularization, and extension. Starting w/ a
noop/RR-scheduler, each step would need to be analyzed for stability and
efficiency, before moving to the next step, thus exposing problems as you
move from step to step.
Thanks!
--
Al
next prev parent reply other threads:[~2006-04-16 19:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200604112100.28725.kernel@kolivas.org>
2006-04-11 17:03 ` Fwd: Re: [patch][rfc] " Al Boldi
2006-04-11 22:56 ` Con Kolivas
2006-04-12 5:41 ` Al Boldi
2006-04-12 6:22 ` Con Kolivas
2006-04-12 8:17 ` Al Boldi
2006-04-12 9:36 ` Con Kolivas
2006-04-12 10:39 ` Al Boldi
2006-04-12 11:27 ` Con Kolivas
2006-04-12 15:25 ` Al Boldi
2006-04-13 11:51 ` Con Kolivas
2006-04-14 3:16 ` Al Boldi
2006-04-15 7:05 ` Con Kolivas
2006-04-15 18:23 ` [ck] " Michael Gerdau
2006-04-15 20:45 ` Al Boldi
2006-04-15 23:22 ` Con Kolivas
2006-04-16 18:44 ` [ck] " Andreas Mohr
2006-04-17 0:08 ` Con Kolivas
2006-04-19 8:37 ` Andreas Mohr
2006-04-19 8:59 ` jos poortvliet
2006-04-15 22:32 ` jos poortvliet
2006-04-15 23:06 ` Con Kolivas
2006-04-16 6:02 ` Con Kolivas
2006-04-16 8:31 ` Al Boldi
2006-04-16 8:58 ` Con Kolivas
2006-04-16 10:37 ` was " Con Kolivas
2006-04-16 19:03 ` Al Boldi [this message]
2006-04-16 23:26 ` Con Kolivas
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=200604162203.32193.a1426z@gawab.com \
--to=a1426z@gawab.com \
--cc=ck@vds.kolivas.org \
--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
all inboxes | Powered by JetHome®