From: Con Kolivas <kernel@kolivas.org>
To: Al Boldi <a1426z@gawab.com>
Cc: ck list <ck@vds.kolivas.org>, linux-kernel@vger.kernel.org
Subject: Re: was Re: quell interactive feeding frenzy
Date: Mon, 17 Apr 2006 09:26:06 +1000 [thread overview]
Message-ID: <200604170926.07516.kernel@kolivas.org> (raw)
In-Reply-To: <200604162203.32193.a1426z@gawab.com>
On Monday 17 April 2006 05:03, Al Boldi wrote:
> It's not bad, but it seems to allow cpu-hogs to steal left-over timeslices,
> which increases unfairness as the proc load increases.
Spot on.
> 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.
Not interested in hacking on something like that onto it. It was more of an
experiment in the simplest possible starvation free design that still
supported nice levels.
> 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.
While this may be the key, it is not the reason we aren't getting maximum
roundness in our designs in linux. Our major enemy is cpu accounting of work
done in kernel context on behalf of everyone else. Putting architecture
dependant hooks into the assembly code to account for entry and exit would be
the accurate way of doing this.
--
-ck
prev parent reply other threads:[~2006-04-16 23:26 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] quell interactive feeding frenzy 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
2006-04-16 23:26 ` Con Kolivas [this message]
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=200604170926.07516.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=a1426z@gawab.com \
--cc=ck@vds.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