From: davidsen@tmr.com (bill davidsen)
To: linux-kernel@vger.kernel.org
Subject: Re: Circular Convolution scheduler
Date: 21 Oct 2003 18:51:10 GMT [thread overview]
Message-ID: <bn3v6u$hv6$1@gatekeeper.tmr.com> (raw)
In-Reply-To: 20031019085008.7505.qmail@email.com
In article <20031019085008.7505.qmail@email.com>,
Clayton Weaver <cgweav@email.com> wrote:
| (perhaps a bit less vague)
|
| While the long-term time series analyses
| would doubtless be interesting for enterprise
| networks, I had something more modest in mind.
|
| Most of the heuristic work so far seems to have
| been directed toward how to identify interactive
| processes as interactive without false positives
| on batch processes, making the code correct (no
| bugs), making it fast, and a little tuning to
| obtain generally ("for most people") usable
| values for how fast to scale up the priority
| on a process that has matched the heuristics,
| yes?
|
| My question about inserting a convolution
| would be more relevant to what do we do
| with that information ("we believe that
| this process is interactive")once we have it.
I think that's the right point, but the advantage of better analysis may
not be in better finding which process does what, but deciding which
type of process we want to run and for how long. The reports of starving
this and that indicate that giving the "most interactive" process all it
can use may not be the best for the system responsiveness overall.
And the observed results from various fairness and deadline scheduling
seem to bear this out. Instead of using an override "this process has
waited too long" model, a better schudling in normal mode might be
possible.
Just my thought, not "do the same old but better," but "make better
choices for the system overall." That could target throughput or
responsiveness as desired.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
next prev parent reply other threads:[~2003-10-21 19:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-19 8:50 Circular Convolution scheduler Clayton Weaver
2003-10-21 18:51 ` bill davidsen [this message]
-- strict thread matches above, loose matches on Subject: below --
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-07 20:47 Clayton Weaver
2003-10-06 16:17 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
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
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='bn3v6u$hv6$1@gatekeeper.tmr.com' \
--to=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